Let me start with a quick intro and background about NGen. With CLR execution model, you write code using your favorite language like C#, VB.NET, C++/CLI and then compiled into a .NET assembly. The .NET assembly contains code in form of Intermediate Language. When you run the program, Just In Time compiles your program into native code, which could mean taking a performance hit. NGen is a tool that could be used to create those native images and install into local assembly cache. A common practice is that installers during program installation used NGen to pre-compile the assemblies into processor and CLR specific native images. These assemblies are located at C:\Windows\Assembly with different folders specific for CLR version and processor architecture. That’s why these folder name contains 32, 64 and CLR version, as shown in figure below.
Given that .NET assemblies contain data as IL and are vulnerable to assembly tampering attack, there is misconception that by pre-compiling these assemblies into native images somehow makes them hack proof. This is actually not completely correct. Reason is that at runtime CLR still need to get access for assembly’s metadata and for that purpose you still need to ship your managed assemblies (containing IL) even though you are pre-compiling your assemblies using NGen. In addition, in some cases NGened assemblies sometimes get out of sync and in that case CLR goes back to original assemblies to perform JITing.
Until next, happy debugging.
Error: Twitter did not respond. Please wait a few minutes and refresh this page.