I am working on an app that will load plug-ins. The plug-in assemblies reside in a directory that is below my app’s main directory.
Looks like this:
MyAppFolder ----------->ThePluginFolder ----------------Assembly1 ----------------Dependency1
My problem occurs with Dependency1 (this is an assembly that Assembly 1 references). The CLR fails to find it.
I have done some reading on Fusion, and it looks as though I could correct this by setting a Private Path with currentAppDomain.AppendPrivatePath.
However, in the .NET 4.0 help, they say that this method is obsolete. They point me to the AppDomainSetup, but I can’t use that to modify my current app domain.
Does anyone know what else I can do to get these dependencies to load?
Options I’ve considered:
-
I could manually loop through Assembly1’s references, and if I find an assembly in the plug-in folder, I could manually load it. (seems like my best option, but I want to make sure I’m not missing anything)
-
I could hook the AssemblyResolve event of my current domain (but this even looks weird — you return a value. Does that imply that it’s not multicast? I’m handling one aspect of plug-in (a business rule), what if another part of my app wanted plug-in reports? Would I need 1 global event handler?
Thanks for all the help, guys. In my case, I found that the best thing to do was to locate the plugins in my main application directory. Although I could ues Load() or LoadFrom() to load the assemblies in separate dirs (and it would appear to work), I later ran into serializtion problems (the referred to assembly had classes that need to be serialized and deserialized).
I tried using LoadFrom() and Load(), supplying various evidence in the AssmblyName parameter. I even “manually” loading the assemblies that were referenced by my plug-ins. No amount of dynamic loading would make deserialization work (I got exceptions).
I only found 3 ways to have my dynamically loaded plug-ins work with serialization:
Use CurrentDomain.AppendPrivatePath to add a path to the directory that had my assemblies (this method is obsolete)
Hook the ResolveAssembly event in the current AppDomain (this would have worked, but it gets called alot, and I don’t want to impact my application’s performance — note that I haven’t taken measurements, though).
Just put the assemblies in my main directory. (this was the simplest solution, and the only argument against doing so was that the directory structure was not as tidy as my other options. So, all things considered. I took this route.