Can I determine what triggered an assembly load?

Question

When windows service installer is bombing out with a "Error 1001. Unable to get installer types in the MyService.exe assembly." So it can't load MyServiceInstaller. Fusion logging is showing me that it is failing when trying to find my Data.dll assembly.

The thing is, it should not need to load Data.dll to create my service installer object. I thought that type loading was not triggered until just before a method containing those types was called. Some MyServiceInstaller methods reference types from Data.dll, but not any ctor.

It's as if the act of loading MyService.exe, or probing for MyServiceInstaller, invokes the load of Data.dll.

As I understand it, fusion logging will not tell me what I need to know. It's too late at that point. I need to know what it is about loading MyServer.exe or the probing for MyServiceInstaller that triggered the loading of Data.dll in the first place.

There is a business requirement that Data.dll cannot be placed next to MyService.exe. And indeed, that does solve this problem. I have a custom AssemblyResolve event which loads Data.dll at normal runtime.

Answer 1

Perhaps there is an instance variable (field) of a type defined in Data.dll; when MyServiceInstaller is loaded, the types for all fields need to be available, even if they're not used, because the class is being compiled if an instance is created.

Answer 2

Try to attach a debugger to the installer and make it break when the exception is thrown (you can set that up in Visual Studio in Debug/Exceptions). Normally there should be a FileNotFoundException or something similar thrown internally in the installer when the assembly load fails which is probably catched somewhere else but if you make the debugger to break when the exception is being thrown (and not when it's unhandled) you can step in and get a stack trace which should help you at discovering what exactly caused the problem.

You should see something like that in the stack trace:

• [Uninteresting native and / or external code]
• SomeClassInYourInstaller.SomeMethod() <-- this is the responsible method
• SomeOtherStuff.SomeMethod()
• ...etc...