Зависимости сборки собрания в среде MEF

Question

У меня есть приложение, в котором я использую MEF для динамической загрузки сборных сборок. Одна сборка является доменным уровнем, вторая - видом. Доменная сборка сборок и работает как ожидалось. Структура псевдо выглядит следующим образом:

• Решение
  • Проект Домен
  • View Project

вопрос, который я имею в том, что вид сборки содержит 1..n пользовательские элементы управления, которые являются визуальными прокси-серверами для объектов домена в первой сборке. Это помещает ограничение на сборку вида в том смысле, что оно зависит от сборки уровня домена. например сверху, сборка Project View зависит от сборки Project Project. Я подозреваю, что перемещение визуальных прокси из проекта вида в проект домена решит проблему, однако это будет идти против разделения проблем.

При вызове метода Assembly.LoadFile() на сборке просмотра я получаю типичное исключение FileNotFoundException. Я считаю, что это связано с тем, что сборка уровня домена сначала загружается за пределы корня приложения приложения и, следовательно, не находится в пределах пути зонда. То, на что я надеялся в этом процессе, было бы потому, что основная сборка уже была загружена, что зависимость, которую имеет сборка просмотра, была бы удовлетворена. К сожалению, это было не так.

AppDomainSetup.PrivateBinPath не является для меня вариантом. Это создало бы ограничения для разработчиков расширений для установки в файловой структуре, где было установлено приложение, которое приведет к загрязнению, и это не то, что нам нужно или нужно. Я знаю, насколько проще, чтобы эта задача имела один каталог Extensions под установленным корнем приложения.

Что я хотел бы сделать, так это иметь возможность загружать сборки и выполнять их зависимости другими сборками, которые уже были загружены и добавлены в AggregateCatalog.

Есть ли у кого-нибудь мысли, предложения или советы, которые могут помочь мне достичь моей цели?

Answer 1

Хорошо, решение для меня было не использовать module initialization through assembly injection. Хотя он довольно изобретателен, он, похоже, вообще не вызван для фреймворка 4 при загрузке сборки из C#. Он может работать при других обстоятельствах.

Решение для меня состояло в том, чтобы вернуться к основам и полагаться на текущее событие AssemblyResolve AppDomain. Во-первых, при создании ComposablePartCatalog моих расширений я сохранил мои пути расширения в коллекции. При сбое загрузки сборки событие AssemblyResolve срабатывает, и я повторяю свою коллекцию путей расширения, ища зависимость расширения.

Это вполне соответствует моей цели - поддерживать разделение между установленным приложением и любыми установленными расширениями.