Native Assembly Generation

One of the first things that people might notice when they're running managed applications is that the startup time is slower than it is for a "native" application. The major cause of this slowdown is the actual compilation that needs to happen (just in time [JIT] compiling). Because the managed code must be compiled into native code before it's executed, this compilation provides an expected delay when starting the application. Because Managed DirectX is built on top of this system, code you write using the Managed DirectX runtime has this behavior as well.

Because the JIT compilation can do a lot of optimizations that just can't happen during compile time (taking advantage of the actual machine the code is running on rather than the machine it was compiled on, and so on) the behavior here is desired. The side effect (the slowdown) is not. It would be great to find a way to remove this cost. Luckily for us, the .NET Framework includes a utility called Native Image Generator (NGen), which does exactly that.

This utility natively compiles an assembly and puts the output into what is called the native assembly cache, which resides within the global assembly cache. When the .NET Framework attempts to load an assembly, it checks whether the native version of the assembly exists, and if it does, it loads that instead of doing the JIT compilation at startup time, potentially dramatically decreasing the startup time of the application using these assemblies. The downsides of using this utility are twofold. First, there's no guarantee that the startup or execution time will be faster (although in most cases it is so you should test to find out), and second, the native image is "fragile." A number of factors cause the native image to become invalid (such as a new runtime installation or security settings changes). After the native image is invalid, it still exists in the native assembly cache and is never used. Plus, if you want to regain the benefits, you need to NGen the assemblies once more, and unless you're watching closely, you might not even notice that the original native assemblies are now invalid.

If you've decided you would still like to NGen your Managed DirectX assemblies, here are the steps you would take:

1.	Open a Visual Studio .NET 2003 command prompt.
2.	If you do not want to open that command window, you could simply open a normal command prompt window and ensure that the framework binary folder is in your path. The framework binary folder should be located at %windir%\microsoft.net\framework\v1.1.4322, where %windir% is your Windows folder.
3.	Change the directory to %windir%\microsoft.net\Managed DirectX, where %windir% is your Windows folder.
4.	Go into the folder for the version of Managed DirectX you want to NGen from here (the later the version, the more recent the assembly).
5.	Run the following command line for each of the assemblies in the folder: ngen microsoft.directx.dll (etc) If your command prompt supports it, you might also use this command line instead: for /R %i in (*.dll) do ngen %i

If you later decide you do not want the assemblies compiled natively, you can use the ngen /delete command to remove these now compiled assemblies.

Construction Cue

Note that not all methods or types are natively compiled by NGen, and they still need to be "JITed." Any types or methods that fall into this category will be output during the running of the NGen executable.