How to Compile with ngen.exe and How to run the native code that is generated?

Question

I want to compile a C# program using ngen command line for a special purpose. So I create a console application in VS2010 and named it ngentest. A file by name ngentest.vshost.exe is created in vs2010\projects\ngentest\bin\debug. I used this file as a ngen command argument in VS2010 command prompt, as follows:

ngen "c:\documents\vs2010\projects\ngentest\bin\debug\ngentest.vshost.exe"

But when I do this, I can't receive PublicKeyToken and I couldn't find any assembly anywhere! If my assembly is created, where it is? And how I can find it? How I can run it(with command, or...!) to get my output?

Otherwise when I build my project with build ngen from Build menu from VS, some file were created in mentioned directory, and one of them is ngentest.exe.

Solution

When you compile your C# code, it gets compiled into an IL assembly. And NGEN takes IL assembly as an input and installs the assembly and its dependencies into Native Image Cache.

For your example binary, you need to open an admin VS Command prompt, then type the following

ngen install ngentest.exe

This would install your exe and its dependency dll files into the Native Image Cache. You use the filename to the assembly here.

Then when you run your exe, the .NET runtime will load and run the native image installed to the Native Image Cache. You don't need to take any extra step to have .NET run the Native Image. The runtime checks the Native Image Cache to see if there is a valid Native Image for the IL assembly.

You can verify that a native image is installed by typing the following command:

ngen display ngentest

In this case you must use the assembly name. Note that 32 bit ngen will only install and display 32 bit, assemblies and 64 bit ngen only 64 bitassemblies.

See http://blogs.msdn.com/b/junfeng/archive/2007/02/18/native-image-loading.aspx for more info on Native Image loading.

Note that ngentest.vhost.exe is an artifact created by VS to provide better debugging experience. It is used by VS. You shouldn't be using that for NGEN or anything for that matter. See the question: What is the purpose of the vshost.exe file? for more info.

Comments

[Kris Vandermotten]

First of all, you should do this on ngentest.exe, not on ngentest.vshost.exe. Secondly, where it is stored doesn't matter, the system will find it for you. It's somewhere in a hidden folder under your Windows directory.

[Azad]

but as I understand the ngentest.exe contains MSIL code, but ngen needs managed code to generate binary code(machine specific). and if I use command "ngen ngentest.exe", how i can run my project?

[Azad]

I read this page, but it couldn't help me...

[Kris Vandermotten]

The first paragraph on that page is "The Native Image Generator (Ngen.exe) is a tool that improves the performance of managed applications. Ngen.exe creates native images, which are files containing compiled processor-specific machine code, and installs them into the native image cache on the local computer. The runtime can use native images from the cache instead of using the just-in-time (JIT) compiler to compile the original assembly." What part do you not understand?

[Azad]

How runtime running this native images? and what should I do?

[Marvin Smit]

Read up on the "Fusion Engine" and you'll know where .Net load assemblies from

[Offler]

If i am on a client machine I won't have a VC Command Promt. Where is ngen in .net 4.5?

[m_eric]

ngen.exe is located in the framework directory: %windir%\Microsoft.NET\Framework\v4.0.30319\ngen.exe for 32bit and %windir%\Microsoft.NET\Framework64\v4.0.30319\ngen.exe for 64bit

[user2173353]

To make the answer better, I think this piece of info would be nice: When there is a change to your assembly, after you install the update, you just need to simply call "ngen.exe update", and CLR will automatically regenerate all the native images affected by the change to your assembly. Weird that this does not accept a file path though... :^)

[Aisah Hamzah]

@user21, running update is recommended by Microsoft, but is very slow. It'll go over all assemblies in your entire system, which can take minutes. Alternatively, consider just running install again. This updates only the dependencies.