How should I organize reference assemblies for AddIns when using Microsoft AddIn Framework

Question

Here is my scenario:

I am using the Microsoft AddIn Framework for my project in order to have a nice plugin architecture. I also have a custom API I made compiled into a dll. The host application and all of the addins need to reference this api. Obviously when using this framework all of the addins must be in their own directory inside the AddIns directory.

From my experience so far, any assembly that an individual addin references must be put in the individual addin's directory or it won't be found resulting in an exception. In my case every addin references the API and thus, must have that dll in it's directory. This means I have a bunch of copies of my API dll which seems unnecessary. I would rather have just one place where I can put my required assemblies (like a lib folder at the application root) where the host and all the addins can find them. Is this possible? Maybe loading the addins differently (appdomain?) would allow them to look in the host app directory. I am relatively new to MAF so any advice on how to do this organization would be helpful.

Answer 1

One of the things that you cannot do in .Net is unload a DLL from an AppDomain once it has been loaded. You may want to do this (say) if different AddIns use different versions of a 3rd party DLL with different API signatures. MAF can support this by instantiating a new AppDomain per AddIn - each AppDomain having it's own version of the 3rd party DLL.

This is why you need to have a separate copy of the 3rd party DLL in each AddIn folder: allowing you to isolate each AddIn from changes in implementation or dependencies in other AddIns.

However the answer also partially depends on how .Net resolves assembly dependencies and how you are activating the AddIns.

.Net will probe for assembly dependencies in the BaseDirectory and PrivateBinPath of the AppDomain that a type is used within (excluding the GAC).

When you actvate an AddIn, it is done inside an AppDomain. If you don't specify one, you will get a new AppDomain for each AddIn and that AppDomain will have the BaseDir set to the AddIn folder - and thus 3rd party DLLs will be found there.

If you do specify an AppDomain, then dependent assemblies will be looked for in the BaseDir and PrivateBinPath of that appdomain. This can have the effect of totally ignoring any 3rd party DLLs in the AddIn folder altogether!

Remember that MAF also has funky rules around the AddIn directory structure - it even prohibits the AddIn view DLLs being in the AddIn directory itself.

The conclusion that I have come to that in order to support all the different activation modes of an AddIn, is there should only be a single DLL in the AddIn folder. We are updating our build process to ilmerge all dependent DLLs into the AddIn dll, including satellite assemblies, Sgen serialization DLLs and also 3rd party DLLs.

With that in mind, perhaps you should look to solve the "duplicate DLL" problem in your build process?

Answer 2

1. If deploying your "common" assembly to the GAC is an option, it should allow any loading assembly to bind
2. If you are deploying an isolated application, you can try placing your common assembly(ies) in the same folder with the exe, or add a probing mapping to its location:

<runtime> <assemblyBinding xmlns="urn:schemas=microsoft-com:asm.v1"> <probing privatePath="myfolder"/> </assemblyBinding> </runtime>

see more details http://www.thescarms.com/dotnet/Assembly.aspx