I'm trying to measure the performance impact of NGENing my assemblies versus not but I am unable to get my executable to load the NGEN assemblies. I ran the following from the VS2010 command prompt:
ngen install MyApp.exe
This completed without any issues and I verified that all my dependency assemblies had been created in the C:\Windows\assembly\NativeImages_v4.0.30319_32\MyCompanyName# directory.
I then launched my app and looking at Process Explorer, it was loading all my assemblies from the local binaries directory instead of loading the *.ni.dll files from the NativeImages_x folder. I logged the bindings using fuslogvw. Here is a sample log entry:
*** Assembly Binder Log Entry (6/29/2011 @ 10:14:04 AM) ***
The operation failed.
Bind result: hr = 0x80070002. The system cannot find the file specified.
Assembly manager loaded from: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll
Running under executable C:\Path\To\My\Binaries\MyCompanyName.MyApp.exe
--- A detailed error log follows.
=== Pre-bind state information ===
LOG: User = username
LOG: DisplayName = MyCompanyName.MyAssembly, Version=1.0.2.0, Culture=neutral, PublicKeyToken=null
(Fully-specified)
LOG: Appbase = file:///C:/Path/To/My/Binaries/
LOG: Initial PrivatePath = NULL
LOG: Dynamic Base = NULL
LOG: Cache Base = NULL
LOG: AppName = MyCompanyName.MyApp.exe
Calling assembly : MyCompanyName.AnotherAssembly, Version=1.0.2.0, Culture=neutral, PublicKeyToken=null.
===
LOG: Start binding of native image MyCompanyName.MyAssembly, Version=1.0.2.0, Culture=neutral, PublicKeyToken=null.
WRN: No matching native image found.
LOG: IL assembly loaded from C:\Path\To\My\Binaries\MyCompanyName.MyAssembly.dll
Does anyone have any thoughts on what is going on here? I verified that the native assembly in question exists at:
C:\Windows\assembly\NativeImages_v4.0.30319_32\MyCompanyName#\3a041121abf7fbdce89836c32f2d217e\MyCompanyName.MyAssembly.ni.dll
Why isn't it binding it correctly? FWIW, the application uses MEF quite a bit; I don't know if that would affect the loading of the assemblies.
I don't know what the actual issue was but the solution was to write a batch file that simply NGEN'd every binary in the directory. I guess there were binaries that were not being NGEN'd when running just the ngen install command on the top-level exe.