У меня есть приложение, в котором я использую MEF для динамической загрузки сборок расширения. Одна сборка - это слой домена, вторая - представление. Сборка домена загружается и работает как положено. Псевдоструктура выглядит следующим образом:
- Решение
- Домен Project
- Просмотр проекта
Проблема, с которой я столкнулся, состоит в том, что сборка представления содержит 1..N пользовательские элементы управления, которые являются визуальными прокси для объектов домена в первой сборке. Это накладывает ограничение на сборку представления в том смысле, что оно зависит от сборки уровня домена. например сверху сборка View Project зависит от сборки Domain Project. Я подозреваю, что перемещение визуальных прокси-серверов из проекта представления в проект домена решит проблему, однако это будет противоречить разделению интересов.
При вызове метода Assembly.LoadFile () для сборки представления я получаю типичное исключение FileNotFoundException. Я полагаю, что это связано с тем, что загруженная сборка доменного уровня сначала находится вне корневого каталога, в котором выполняется приложение, и, следовательно, не входит в путь зондирования. В этом процессе я надеялся, что, поскольку сборка ядра уже загружена, зависимость сборки представления от него будет удовлетворена. К сожалению, это был не тот случай.
AppDomainSetup.PrivateBinPath не вариант для меня. Это наложит ограничения на разработчиков расширений для установки в файловой структуре, в которой установлено приложение, что приведет к загрязнению, а это не то, что нам нужно или нужно. Я знаю, насколько проще было бы, чтобы эта задача имела один каталог Extensions в корневом каталоге установленного приложения.
Что я хотел бы сделать, так это уметь загружать сборки и встречать их зависимости с другими сборками, которые уже были загружены и добавлены в AggregateCatalog.
У кого-нибудь есть мысли, предложения или советы, которые могут помочь мне достичь моей цели?