Extensible Excel VSTO Add-in using Prism / CAG / Unity debugging

I'm developing an Excel VSTO Document Level Add-In using Composite Application Guidance (Prism for Visual Studio开发者_开发问答 2008/.NET 3.5).

One of the requirements is that this add-in should be extensible, that is it should allow loading plugin dlls during runtime. I'm creating unity's directory module catalog like this:

// the path where the WorkbookProject.dll Add-In (WorkbookProject\bin\Debug) resides
string fullPath = AppDomain.CurrentDomain.BaseDirectory;
string theDirectory = Path.GetDirectoryName(fullPath);

return new DirectoryModuleCatalog() { ModulePath = fullPath };

My simplified projects hierarchy is like this:

Common
-ref: none

WorkbookProject // the main project with xlsx workbook (shouldn't reference any PlugIns)
-ref: Common

PluginOne
-ref: Common
-PostBuildEvent copies output dll to WorkbookProject\bin\Debug

Setup (temporarily knows all plugins, but they should be installed separately)
-ref: Common
-ref: PluginOne
-ref: WorkbookProject

This works fine after deployment (all dlls reside in the Application Folder as created by setup project), but during debug i get the exception on Microsoft.Practices.Composite.Modularity.ModuleCatalog.Load():

System.IO.FileLoadException: API restriction: The assembly 'file:///(...)\WorkbookProject\bin\Debug\Common.dll' has already loaded from a different location. It cannot be loaded from a new location within the same appdomain.

In Visual Studio Output/Debug window I can see that this file has already been loaded from

C:\Users\Me\AppData\Local\assembly\dl3\JWCWD78V.HAZ\H2VHNAYM.XW1\18912686\7e8ea552_620acc01\Common.dll

Why all my application files (referenced from WorkbookProject) get copied to AppData Directory during debug? Is it possible to avoid this?

Would it make a difference if I converted my project from Workbook Add-In to Application Add-In?

Well, I think I managed to solve the problem.

It seems that there was a version mismatch on Common.dll.

I noticed that in my Debug Configuration the PluginOne was not checked for Build, so during Debug an old version of PluginOne was loaded.

After I corrected this and re-added all references to Common.dll the problem does not appear.

Now my PluginOne.dll loads from AppData (note that it happens during runtime on the fly, since the DirectoryModuleCatalog path is WorkBookProject\bin\Debug, and I don't have any reference to the PluginOne in my .VSTO or WorkbookProject.dll.manifest)

Also note, that when you use Composite Application Guidance for VS2008, the specified folder for DirectoryModuleCatalog cannot contain native dll's, or BadImageFormatException would be thrown. Use subdir: ModulePath=fullPath+"\Modules" or see GetNotAllreadyLoadedModuleInfos() method in V4 version of Prism for a quick fix)

This is a really interesting use of VSTO, you seemed to have sorted your issue but I am just wondering if you would be better off using a more recent technology stack to achieve this.

Using MEF for the add-in architecture over Prism can be cleaner because the reasons for each project are vastly different, and MEF has a cleaner model I think, it can also act as a basic IoC container. A container like Autofac also gives you much more explicit lifetime management than unity, which can be an advantage when working with COM Interop.
I also have a project vsto contrib (http://vstocontrib.codeplex.com/) which may also help you out, especially if you have ribbon's and other things registered via add-ins.

Just my 2c on the approach, but overall, very cool that you are doing all this with VSTO.