plug-in assemblies sharing a library

Question

My application includes a plug-in architecture, where DLLs, meeting certain criteria, placed in subdirectories of a well-known directory will be loaded into the application as needed.

Plug-in assemblies are not always self-contained. Some library DLLs are sometimes required. These are placed next to each plug-in assembly. They don't meet the plug-in criteria, so they don't get loaded as plug-ins, but they get loaded by plug-ins.

Sometimes, more than one plug-in uses the exact same version of the same library. There is then a copy of the associated DLL in more than one plug-in directory.

This all works fine until someone decides that they don't need a certain plug-in and deletes its subdirectory. The application detects this fine, so it won't try to use that plug-in any more. But, if that plug-in had a copy of a library DLL that is also used by another plug-in, one can experience exceptions.

I believe that this happens because .Net will only load that specific version of the library once per run of the application. And the particular file that it loads it from is the one next to whichever plug-in happens to be used first. If that plug-in happens to be the one that's been deleted, then any other plug-ins using the same library will blow up, because they try to use the now-deleted DLL.

The plug-in assemblies are loaded using Assembly.LoadFrom(path). I don't think that I can use LoadFile(path), because that doesn't cope with references to other DLLs. And I can't use Load(typename), because what I have is the path, not the type name.

Restarting the application fixes the problem, but that currently only happens "manually", after a failure.

Does anyone have a suggestion either for: -

• Recovering from the problem, for instance by persuading .Net to change where it looks for that DLL
• Persuading the Web application containing the plug-in to re-start automatically in this situation
• Rearchitecting to avoid the problem (but this is a mature in-use application, so my options are limited)

Answer 1

Easy way is to go with an xml identifying the plugins, common references and their dependencies. Common references section will have all dlls that other plug-ins are depend upon and are placed in separate folder. Something like below should work for you:

<CommonReferences>
   <Dll id="" path="" version=""/>
   <Dll id="" path="" version=""/>
</CommonReferences>
<Plugins>
   <Plugin id="" path="" version="">
     <Dependencies>
         <DependencyDll id="" path="" version=""/>
         <DependencyDll id="" path="" version=""/>
         <DependencyDll id="" path="" version=""/>
     </Dependencies>
   </Plugin>
</Plugins>