Как мне организовать справочные сборки для надстроек при использовании Microsoft AddIn Framework - PullRequest
Новая
       23

Как мне организовать справочные сборки для надстроек при использовании Microsoft AddIn Framework

0 голосов
/ 10 марта 2011

Вот мой сценарий:

Я использую Microsoft AddIn Framework для своего проекта, чтобы иметь хорошую архитектуру плагинов. У меня также есть собственный API, который я скомпилировал в dll. Хост-приложение и все надстройки должны ссылаться на этот API. Очевидно, что при использовании этого фреймворка все надстройки должны находиться в своем собственном каталоге внутри каталога AddIns.

Исходя из моего опыта, любая сборка, на которую ссылается отдельное дополнение, должна быть помещена в каталог отдельного дополнения, иначе она не будет найдена, что приведет к исключению. В моем случае каждый плагин ссылается на API и, следовательно, должен иметь эту DLL в своем каталоге. Это означает, что у меня есть куча копий моей библиотеки DLL, которая кажется ненужной. Я предпочел бы иметь только одно место, где я могу разместить свои необходимые сборки (например, папку lib в корне приложения), где их могут найти хост и все надстройки. Это возможно? Может быть, загрузка надстроек по-другому (appdomain?) Позволит им искать в каталоге приложения хоста. Я относительно новичок в MAF, поэтому любые советы о том, как сделать эту организацию, будут полезны.

Ответы [ 2 ]

1 голос
/ 14 марта 2016

Одна из вещей, которую вы не можете сделать в .Net, - выгрузить DLL из домена приложения после его загрузки.Возможно, вы захотите сделать это (скажем), если разные надстройки используют разные версии сторонних библиотек DLL с разными сигнатурами API.MAF может поддерживать это, создавая новый AppDomain для каждого AddIn - каждый AppDomain имеет свою собственную версию сторонней DLL.

Вот почему вам необходимо иметь отдельную копию сторонней DLL в каждой папке AddIn:позволяя вам изолировать каждый AddIn от изменений в реализации или зависимостей в других AddIns.

Однако ответ также частично зависит от того, как .Net разрешает зависимости сборок и как вы активируете AddIns.

.Net будет проверять наличие сборочных зависимостей в BaseDirectory и PrivateBinPath AppDomain, в котором используется тип (исключая GAC).

Когда вы активируете AddIn, это делается внутри AppDomain.Если вы не укажете один, вы получите новый AppDomain для каждого AddIn, и для этого AppDomain будет установлен BaseDir в папку AddIn - и, таким образом, будут найдены сторонние DLL.

Если вы укажете домен приложения, то зависимые сборки будут искать в BaseDir и PrivateBinPath этого домена приложения.Это может привести к полному игнорированию любых сторонних библиотек DLL в папке AddIn!

Помните, что MAF также имеет нестандартные правила в отношении структуры каталогов AddIn - он даже запрещает DLL-файлы представления AddIn находиться в самом каталоге AddIn..

Я пришел к выводу, что для поддержки всех различных режимов активации AddIn в папке AddIn должна быть только одна DLL .Мы обновляем наш процесс сборки, чтобы погрузить все зависимые библиотеки DLL в библиотеку AddIn, включая сателлитные сборки, библиотеки сериализации Sgen, а также сторонние библиотеки DLL.

Имея это в виду, возможно, вам стоит поискать «дублирующую DLL"проблема в процессе сборки?

0 голосов
/ 17 марта 2011
  1. Если развертывание вашей «общей» сборки в GAC является опцией, это должно разрешить привязку любой загрузочной сборки
  2. Если вы развертываете изолированное приложение, вы можете попробовать поместить вашу общую сборку (и) в одну папку с exe-файлом или добавить сопоставление зондов в его местоположение:

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

подробнее http://www.thescarms.com/dotnet/Assembly.aspx

...