您可以将.NET Native视为桌面CLR使用的NGen技术的演变。 .NET Native和NGEN有几种不同的主要方式 -
- 运行时依赖性 - NGEN使用完整的桌面CLR，.NET Native使用重构的运行时（mrt100_app.dll），它是应用程序本地的。 .NET Native运行时已经过重构，可以将大多数功能从应用程序移到代码生成工具链中。这使得它更小，更有代价，并且（希望）在运行时更可调试。 .NET Native应用程序也是自包含的，这对于应用程序来说是一个有用的属性。
- 原生图像依赖性 - NGEN图像与其运行的CLR和其依赖程序集的NGEN图像紧密绑定。例如，当对mscorlib.dll进行错误修复时，这会导致几乎所有NGEN映像都需要重新生成。
- 编译位置 - .NET Native的目标是在应用商店中生成本机代码。 NGEN在最终用户设备上生成本机代码。您当然可以想象，对于某些类别的设备（例如手机，平板电脑），您更不会浪费最终用户电池寿命生成代码。在商店中进行编译还允许.NET Native花费更多时间进行编译，从而允许它应用比NGEN更多的优化。
- 代码生成器 - NGEN使用JIT编译器生成代码，.NET Native使用Visual C ++编译器的后端，这使我们能够应用太大而无法应用的自动向量化等优化在JIT案例中
- 整个程序分析 - NGEN一次为单个程序集生成代码，允许NGEN映像在多个应用程序上下文中使用。 .NET Native为整个应用程序包生成代码，允许它应用更广泛的优化集（例如，完全丢弃在运行时从未使用过的代码）。这与重构框架相结合，使这些优化能够尽可能地发挥作用。
- IL Fallback - NGEN图像包含程序集的本机代码和MSIL（以及其他数据结构）。如果在运行时发生某些事情导致CLR需要在NGEN映像中找不到的本机代码，它可以回退到JITing。在.NET Native当前的开发人员预览中，本机映像中仅存在本机代码。这意味着如果代码不存在于图像中，它将永远不会在运行时执行。
据我所知，Ngen仍然依赖于.NET Native在根据常见问题解决方案生产时所不具备的框架。
这只是关于性能，还是这也允许构建
C＃代码（比如说）本地编译为Win32 / 64但没有
需要在目标机器上安装.NET Framework吗？
这是正确的：.NET Native不仅仅是性能，还有
关于生产力和一致的设备体验。 .NET Native
允许您使用托管语言编写代码并上传MSIL
包裹一如既往。 但是，应用程序将部署在最终用户上
设备作为完全独立的本机编译代码（当.NET时
Native进入生产），并且不依赖于.NET
目标设备/机器上的框架。如您所知，.NET应用程序
范围广泛。因此，我们在完整的.NET中投入了大量资金
框架也是如此（例如，我们刚刚发布了RyuJIT的CTP）。
Microsoft .NET Native FAQ