4

I am trying to load assemblies dynamically through Reflection. i have folder structure like this:

project
  \-- BIN
       |-- myApp.exe
       |-- SOMEEXTENTION1
       |    |-- someExtention1.dll
       |    \-- itsDependency1.dll
       |         
       |-- SOMEEXTENTION2
            |-- someExtention2.dll
            \-- itsDependency2.dll

I can load someExtention using reflection. Problem occurs when during execution someExtention looks for itsDependency. Dot net looks in BIN folder. It doesn't find it there. Appdomain's AssemblyResolve event is raised...

I am trapping this event. In ResolveEventArgs I get the name of the assembly which needs to be loaded. problem is that i don't get the RequestingAssembly. that property of ResolveEventArgs is always empty. I need the requesting assembly so that I can look directly in its own EXTN folder. without that I have to look in all of the EXTN folders, which in my case can be quite large.

RequestingAssembly has a property Location which according to this msdn article contains the path to the physical file. this article also sites a situation when this property could be Nothing. I dont understand the Load-Context discussed there.

Any help would be appreciable...

inquisitive
  • 3,549
  • 2
  • 21
  • 47

1 Answers1

4

From what i found with experimentation (again no search result in support), when dynamically loading assemblies, the folder name must not match the assembly name. i don't know exactly what happens then, but something inside the loader mechanism goes haywire.

By the way when an assembly is loaded with LoadFrom method, it gets loaded in load-from-context. in this context the dependency assemblies are resolved by first looking at the application-base then at the assembly's own folder. in my case this solvs the problem of resolving dependencies.

on the downside i found that if load-from fails to resolve a dependency and AssemblyResolve event is triggered then requesting assembly will not be available. that means the path-to-requesting-assembly could not be determined.

rather than using load-from, when i used LoadFile method, then the dependencies are NOT automatically resolved from the subfolder. Rather AssemblyResolve event is triggered. in this case though the ResolveEventArgs will contain the requesting assembly property. from where the user code can easily determine the target path. then the user code can load the dependency.

inquisitive
  • 3,549
  • 2
  • 21
  • 47
  • you're right. LoadFrom() generates events that have a RequestingAssembly property, whereas doing `Assembly.Load(AssemblyName.GetAssemblyName(path))` doesn't. I don't get why but I've had to switch – ekkis Sep 27 '13 at 23:35
  • This line saved me tons of time "when dynamically loading assemblies, the folder name must not match the assembly name" . I also noticed that RequestingAssembly is null in the resolver event in this scenario. Microsoft should put a warning about this on the msdn pages for LoadFrom()! –  May 20 '17 at 17:19