Determine if GAC'ed & NGen'ed assemblies are being used

Question

How do I determine if the Native images are being used without the Loader verifing the signature of the assembly at runtime, or even using the GAC'ed assembly?

I have complex system that we're experimenting with NGen but currently we're running the exe from the folder where all the DLL's are located due to a lot of late binding dependencies, looking at Process Explorer, it looks like the Native images are being used, but how can I be sure I'm getting the full benefit and eliminating the Loader Verification step?

Cheers, Graeme.

Update: I'm getting lots of this sort of thing from the Assembly Binding Log viewer:

LOG: [Level 1]Start validating IL dependency MyCompany.Entities, Version=2.0.0.0, Culture=neutral, PublicKeyToken=7cd8595f4671c5dd.
LOG: Dependency evaluation succeeded.

and at the end

LOG: Validation of dependencies succeeded.
LOG: Start loading all the dependencies into load context.
LOG: Loading of dependencies succeeded.
LOG: Bind to native image succeeded.
Native image has correct version information.
Attempting to use native image C:\Windows\assembly\NativeImages_v2.0.50727_32\MyCompany.Mylibrary#\4710bb8309419d707681bd360088181f\MyCompany.MyLibrary.MyClass.ni.dll.
ZAP: Native image has been relocated.
Native image successfully used.

So it's using the Native images but still verifying them, i.e. not using the GAC version even though that's where I created the Native image from, Like so:

ngen install "MyCompany.Entites, Version=2.0.0.0, Culture=neutral, PublicKeyToken=7cd8595f4671c5dd, processorArchitecture=MSIL"

Footnote: This articles seems to imply that if the assemblies are not loaded from the GAC then the verification process will offset the NGen advantages? CLR Inside Out - Improving Application Startup Performance (MSDN)

Update - As Nobugz has pointed out in a comment below, the verification step mentioned above is not performed since 3.5 SP1 see:MSDN Docs on NGen

Mcquoid

Answer 1

You can easily see it from the Fuslogvw.exe tool. Start it from the Visual Studio Command Prompt. Configure it with Log Categories = Native Images, Settings + Log all binds to disk. Run your program. Back to fuslogvw, Refresh. It will show you a list of all assemblies that got loaded.

Double-click an entry to see how the assembly got loaded. If it came from the GAC, you'll see:

LOG: IL assembly loaded from C:\Windows\assembly\GAC_MSIL\blahblah

If the Ngen-ed images was used, you'll see:

LOG: Bind to native image succeeded.

Bereave

+1 this looks promising, but I think it's proving that my native images are being used by not from the GAC, so they're still being validated by the loading, effectively offsetting the ngen advantage, see my edits to orginal Q. – Mcquoid

@dog - Looks clear to me, the assembly doesn't get loaded from the GAC, but it does use the Ngen-ed image. This is normal. Not sure what other issue there may be, strong name validation is skipped in full trust if that's what you're worried about. – Bereave

I've added a footnote, it's the loader verification referred to in that article that I'm trying to eliminate. – Mcquoid

@dog - yes, that's what I meant in my last comment. Verification is skipped since .NET 3.5 SP1, exactly to make startup faster. – Bereave

OK, just to add another spanner to the works.. our client code targets 2.0 as some clients are still running win 2000! looks like i'm going to have to spark up VM..! – Mcquoid

Answer 2

You can see if the assembly came from the GAC pretty easily:

Assembly assembly = Assembly.GetExecutingAssembly();

if (assembly.GlobalAssemblyCache)
{
    Console.WriteLine("I'm in the GAC!");
}

EDIT: found a way...

In order to see if it is NGEN'd, you have to read the assembly directly and see if the Precompile Header field has data as per this page. I'm a bit rusty on getting to that value, but that should do it. I don't see a way to figure it out via the reflection methods.

Gantry

I can determine if they are NGen from looking at the DLL's view pane in Process Explorer, by hovering over the name it gives the full path like... c:\Windows\Assembly\NativeImages_v2.0.5072_32\MyDll.ni.dll – Mcquoid

Added something of a clue to my answer. – Gantry

It looks like it was me, but I didn't do it intentionally, could have been when I was browsing my question from my mobile, I've tried to undo the down-vote, but it's to old, if you make an edit i'll be able to undo my down-vote, my apologies, – Mcquoid

Answer 3

You can use the VMMAP. There, all the .dll (assembly) have location details

In details if your assembly is being loaded from "C:\Windows\assembly\NativeImages(version)..." so your application are using the native image.

Mastoiditis