What is the difference between .NET Native and Nge

The title says it all. I was hoping somebody could explain to me what .NET Native brings to the table that we didn't already have with Ngen.exe.

回答1:

As far as I know Ngen still depends on the framework, which .NET Native don't when it hit production according to the faq.

Is this just about performance, or does this also allow for building C# code (say) that is natively compiled to Win32/64 and doesn’t require an install of the .NET Framework on the target machine?

That is correct: .NET Native is not just about performance, but also about productivity and a consistent device experience. .NET Native allows you to write code using managed languages and upload MSIL packages as always. However, apps will get deployed on end-user devices as fully self-contained natively compiled code (when .NET Native enters production), and will not have a dependency on the .NET Framework on the target device/machine. As you know, .NET applications span a broad spectrum. Thus, we are investing big in the full .NET Framework as well (for example, we just released a CTP of RyuJIT).

Microsoft .NET Native FAQ

回答2:

You can think of .NET Native as an evolution of the NGen technology that the desktop CLR uses. There's a few major ways that .NET Native and NGEN differ -

Runtime dependency - NGEN uses the full desktop CLR, .NET Native uses a refactored runtime (mrt100_app.dll) which is application local. The .NET Native runtime has been refactored to move most functionality out of the application and into the code generation tool chain. This makes it much smaller, more pay for play, and (hopefully) more debuggable at runtime. A .NET Native application is also self-contained, which is a useful property to have for an application.
Native image dependencies - an NGEN image is tightly bound to both the CLR that it runs against and the NGEN image of its dependent assemblies. This, for example, causes nearly all NGEN images to need to be regenerated when a bug fix is made to mscorlib.dll.
Compilation Location - the aim for .NET Native is to have the native code be generated in the app store. NGEN generates native code on the end user device. You can certainly imagine that for certain classes of devices (ie phones, tablets) you'd much rather not waste end-user battery life generating code. Compiling in the store also allows .NET Native to spend more time compiling, therefore allowing it to apply more optimizations than NGEN can afford.
Code generator - NGEN uses the JIT compiler to generate code, .NET Native uses the Visual C++ compiler's back end, which enables us to apply optimizations such as auto-vectorization that are too expensive to apply in the JIT case
Whole program analysis - NGEN generates code for a single assembly at a time, which allows an NGEN image to be used in multiple application contexts. .NET Native generates code for an entire application package, which allows it to apply a broader set of optimizations (for instance, entirely throwing away code that's not ever used at runtime). This is coupled with a refactored framework which enables these optimizations to kick in as much as possible.
IL Fallback - NGEN images contain both the native code and MSIL for an assembly (among other data structures). If something occurs at runtime which causes the CLR to need native code that it cannot find in the NGEN image, it can fall back to JITing. In .NET Native's current developer previews, only native code is present in the native image. This means that if the code isn't present in the image, it will never execute at runtime.