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

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

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

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


plugins .net add-in maf
person Brian    schedule 10.03.2011    source источник

Ответы (2)


arrow_upward
1
arrow_downward

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

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

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

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

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

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

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

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

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

person Peter McEvoy    schedule 14.03.2016

arrow_upward
0
arrow_downward

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

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

см. дополнительные сведения http://www.thescarms.com/dotnet/Assembly.aspx

person maximbr    schedule 17.03.2011
comment
Я бы предпочел не устанавливать dll в GAC и беспокоиться о том, чтобы поддерживать ее в актуальном состоянии. Я также не хочу требовать, чтобы все авторы надстроек включали файл app.config в свой плагин. - person Brian; 28.12.2012