5

This is strange.

I have a windows application that dynamically loads DLLs using Reflection.Assembly.LoadFrom(dll_file_name_here).

It works as expected, until I ILMerge the application with another DLL.

So this scenario works fine:

  • MyApp.exe
  • MyAppComponent.dll
  • Plugin.dll

Once I ILMerge MyApp.exe and MyAppComponent.dll resulting in:

  • MyApp.exe
  • Plugin.dll

Calling Reflection.Assembly.LoadFrom("Plugin.dll") seems to load successfully, however once I try to do anything with it eg:

foreach ( typeAsm in Reflection.Assembly.LoadFrom("Plugin.dll"))

I get an exception "unable to load one or more of the requested types. retrieve the loader exceptions property for more informtion".

The frustrating thing is I can't really debug it, because debugging pre merging works perfectly!

Help?

Steve
  • 159
  • 6
  • Debug it with fuslogvw.exe. An obvious failure scenario is plugin.dll having a dependency on the disappeared myappcomponent.dll – Hans Passant Aug 16 '11 at 03:25

1 Answers1

2

My guess is that Plugin.dll references MyApp.exe or MyAppComponent.dll, which are not binary compatible (MyApp.exe) or not there at all (MyApp.dll) after ILMerging.

If that is the case, you shouldn't ILMerge them.

Chris Shain
  • 50,833
  • 6
  • 93
  • 125
  • Thanks. This helped me find a work-around. What I did was 1. Remove the plugin's reference to the MyApp project. 2. Build and ILMerge MyApp into single exe. 3. Then make plugin reference the executable. It worked a treat. – Steve Aug 16 '11 at 03:33
  • For what it's worth, your solution causes a very tight coupling between the plugin and the (post-ILMerge) MyApp.exe. This is probably a bad design, for a number of reasons. Having the plugin and the app reference a common library which resides in its own DLL is a better pattern, because it separates the plugin's interface from the application's implementation, and vice-versa. – Chris Shain Aug 16 '11 at 04:01