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