Проблемы с динамически загружаемыми ссылками на сборки

У меня есть сборка A, эта сборка динамически загружает сборки B, C и E. И он будет загружать больше в будущем.

Проблема первая:
B ссылается на F и G, когда я пытаюсь выполнить методы в экземпляре типа, объявленного в B, из A, я получаю исключение, говорящее мне, что F не найдено , конечно.
Вопросы:

  1. Как я могу ссылаться на F и G при динамической загрузке сборки B, предполагая, что F и G находятся в той же папке, что и B?
  2. Как я могу ссылаться на F и G при динамической загрузке сборки B, предполагая, что F и G находятся в другой папке?

Проблема вторая:
Это в значительной степени связано с тем, что, пытаясь быстро протестировать некоторые функции, я скопировал упомянутые сборки из папки двоичных файлов B в папку A, что привело к следующему исключению:

Не удалось загрузить файл или сборку «log4net, версия = 1.2.10.0, культура = нейтральная, PublicKeyToken = 1b44e1d426115821» или одну из ее зависимостей. Определение манифеста обнаруженной сборки не соответствует ссылке на сборку. (Исключение из HRESULT: 0x80131040)

Я предполагаю, что это происходит из-за того, что я использую версию log4net, отличную от одной из зависимостей B.
Вопрос:
Какая мера могу ли я предпринять, чтобы избежать таких проблем с версиями?
Будет ли исправление проблемы 1 решить эту проблему? Если нет, то почему?

Должен ли я использовать для этого Autofac?
Поможет ли это мне? Как?

Имейте в виду, что идея сборки A состоит в том, чтобы брать «плагины», и в таком порядке декларативное указание на сборки или их зависимости не является вариантом.


dynamic c# dll assembly-resolution
person bevacqua    schedule 04.11.2011    source источник
comment
Удалось ли решить первую проблему? Выбранный ответ, похоже, касается только второго.   -  person ulu    schedule 20.03.2012

Ответы (1)


arrow_upward
3
arrow_downward

Пока сборки совместимы по версии, вы можете указать CLR загружать конкретную версию независимо от того, для какой версии сборка, от которой вы зависите, была скомпилирована.

Например, добавление этого фрагмента в файл конфигурации приведет к перенаправлению 1.0.0.0-2.0.0.0 сборки System.Web.Mvc на использование 3.0.0.0.

<runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
        <dependentAssembly>
            <assemblyIdentity name="System.Web.Mvc" publicKeyToken="31bf3856ad364e35" />
            <bindingRedirect oldVersion="1.0.0.0-2.0.0.0" newVersion="3.0.0.0" />
        </dependentAssembly>
    </assemblyBinding>
</runtime>

Вы можете использовать тот же принцип для любой сборки, например. log4net.

Тем не менее, вашим предпочтительным решением должно быть получение версии, скомпилированной для правильной версии сборки. Например, log4net доступен в исходном коде, поэтому его легко загрузить и перекомпилировать с обновленными зависимостями.

Если вы точно не знаете, какая сборка вызывает проблему, существует средство под названием Fusion Log Viewer (fuslogvw.exe), которое устанавливается вместе с платформой .NET. Он немного причудлив в использовании, но покажет вам, где именно .NET ищет сборки и любые ошибки, возникающие при разрешении сборок.

person Morten Mertner    schedule 04.11.2011