Расширяемая надстройка Excel VSTO с использованием отладки Prism / CAG / Unity

Question

Я разрабатываю надстройку уровня документа VSTO для Excel с использованием руководства по составным приложениям (Prism для Visual Studio 2008 / .NET 3.5).

Одно из требований заключается в том, что эта надстройка должна быть расширяемойто есть он должен позволять загружать dll плагина во время выполнения.Я создаю каталог модулей каталога Unity следующим образом:

// 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 };

Моя упрощенная иерархия проектов выглядит следующим образом:

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

Это прекрасно работает после развертывания (все библиотеки находятся в папке приложения).как созданный проектом установки), но во время отладки я получаю исключение на 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.

В окне вывода / отладки Visual Studio я вижу, что этот файл уже былзагружается из

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

Почему все файлы моего приложения (на которые ссылается WorkbookProject) копируются в каталог AppData во время отладки?Можно ли этого избежать?

Будет ли иметь значение, если я преобразую свой проект из надстройки рабочей книги в надстройку приложения?

Answer 1

Это действительно интересное использование VSTO, вы, похоже, решили вашу проблему, но мне просто интересно, будет ли вам лучше использовать более современный технологический стек для достижения этой цели.

Использование MEF для архитектуры надстроек над Prism может быть более понятным, поскольку причины каждого проекта сильно различаются, и, как мне кажется, MEF имеет более чистую модель, она также может выступать в качестве основного контейнера IoC. Контейнер, такой как Autofac, также дает вам гораздо более четкое управление временем жизни, чем Unity, что может быть преимуществом при работе с COM Interop.
У меня также есть проект vsto contrib (http://vstocontrib.codeplex.com/), который также может вам помочь, особенно если у вас есть ленты и другие вещи, зарегистрированные через надстройки.

Просто мой 2с на подходе, но в целом, очень круто, что вы делаете все это с VSTO.

Answer 2

Ну, думаю, мне удалось решить проблему.

Похоже, что несоответствие версий на Common.dll.

Я заметил, что в моей конфигурации отладки PluginOne не был проверен для сборки, поэтому во время отладки была загружена старая версия PluginOne.

После того, как я исправил это и снова добавил все ссылки на Common.dll, проблема не появляется.

Теперь мой PluginOne.dll загружается из AppData (обратите внимание, что это происходит во время выполнения на лету, поскольку путь DirectoryModuleCatalog - это WorkBookProject \ bin \ Debug, и у меня нет ссылок на PluginOne в моем .VSTO или WorkbookProject .dll.manifest)

Также обратите внимание, что при использовании Руководства по составному приложению для VS2008 указанная папка для DirectoryModuleCatalog не может содержать нативные библиотеки DLL, иначе будет выдано исключение BadImageFormatException. Используйте subdir: ModulePath=fullPath+"\Modules" или посмотрите метод GetNotAllreadyLoadedModuleInfos () в версии Prism V4 для быстрого исправления)