如果 Ngen 不保护我的应用程序，我何时会合理预期在我的职业生涯中使用此应用程序？
Jeffrey Richter 在他的书中写了一篇很棒的文章，我不知道第三版是否有它，但这是他在 2002 年写关于 Ngen'ing 的一篇很棒的文章，它仍然具有相关性。
亮点：
同时，还有一些潜在的 NGen 文件的问题：
没有知识产权保护。很多人相信 或许可以发送 NGend 文件而不传送文件 包含原始IL代码 从而保持他们的智力 财产是秘密。不幸的是，这 是不可能的。在运行时，CLR 需要访问程序集 元数据和 NGend 文件不 包含元数据。
NGend 文件可能会不同步。当 CLR 加载一个 NGen 的文件比较了一些 的属性关于 先前编译的代码和 当前的执行环境。如果有的话 的属性不匹配，则 NGen 的文件无法使用，并且 使用正常的 JIT 编译过程 相反。
管理不善。 NGen 的文件不会自动删除 程序集被反向卸载 轻松影响 .NET Frameworks 管理和 XCOPY 部署 故事。
较差的加载时间性能（变基）。当 Windows 加载 NGend 文件，它检查是否 文件在其首选基地加载 地址。如果文件无法加载 首选基地址，然后是 Windows 重新定位文件，修复所有 内存地址引用。这是 非常耗时，因为 Windows 必须将整个文件加载到 内存并修改其中的各个字节 文件。欲了解更多信息 变基请参阅我的书： 为 Microsoft 编写应用程序 Windows，第四版（微软 按）。
执行时间性能较差。
在编译代码时，NGen 无法像 JIT 编译器那样对执行环境做出尽可能多的假设。这会导致 NGen.exe 生成具有许多内存引用间接的代码，而这些对于 JIT 编译的代码来说是不必要的
NGen 仅用于编译 IL 以提高性能。 您可能需要研究代码混淆以保护应用程序免受逆向工程的影响。
加载速度才是它真正有用的地方。也就是说，它可以实现高达 2000%（是的，这是正确的）的改进。
编辑：
请注意，JIT 化的代码通常比 NGEN 化的代码更快。