AFAIK, ngen turns MSIL into native code (also reffered to as pre-JIT), however I never payed too much attention at it's startup performance impact. Ngen'd applications still require the .NET base class开发者_开发知识库 libraries (the runtime).
Since the base class libraries have everything our .NET assemblies need (correct?) would it be possible to ship the framework's DLLs with my ngen'd application so that it does not require the runtime to be installed? (e.g., the scenario for most Windows XP machines)
Oh, and please don't bother mentioning Remotesoft's Salamander Linker or Xenocode's Postbuild. They are not for my (and many's) current budget (and they seem to simply bundle the framework in a virtualized enviroinment, which means big download sizes and slow startup times I believe)
EDIT:
I know now, ngen doesn't do what I thought it did. But is it possible to bundle the .NET files with an application, without using a VM?You cannot do this. Many essential components such as the garbage collector are part of the CLR (which is part of the framework runtime), so in order to successfully execute your application you need the framework installed.
Have a look at Microsoft .NET Native:
.NET Native compiles C# to native machine code that performs like C++. You will continue to benefit from the productivity and familiarity of the .NET Framework with the great performance of native code.
It will be integrated in Visual Studio 2014.
That's not how Ngen works. It only bypasses the JIT compilation step. The resulting .ni.dll file only contains machine code, not the metadata of the assembly. You need to keep the original assembly available for that. And the CLR and the .NET framework assemblies must be available on the target machine, requiring you to install .NET.
See How to compile a .NET application to native code? - the consensus looks to be that it's not possible.
精彩评论