Загрузка сборок и их зависимостей
Мое приложение динамически загружает сборки во время выполнения из определенных подпапок. Эти сборки скомпилированы с зависимостями от других сборок. Среда выполнения пытается загрузить их из каталога приложения. Но я хочу поместить их в каталог модулей.
Есть ли способ сообщить среде выполнения, что библиотеки DLL находятся в отдельной подпапке?
Ответы 3
Вы можете использовать элемент <probing> в файле манифеста, чтобы указать среде выполнения искать свои файлы сборки в разных каталогах.
http://msdn.microsoft.com/en-us/library/823z9h8w.aspx
например.:
<configuration>
<runtime>
<assemblyBinding xmlns = "urn:schemas-microsoft-com:asm.v1">
<probing privatePath = "bin;bin2\subbin;bin3"/>
</assemblyBinding>
</runtime>
</configuration>
Один хороший подход, который я использовал в последнее время, - это добавить обработчик событий для события AssemblyResolve AppDomain.
AppDomain currentDomain = AppDomain.CurrentDomain;
currentDomain.AssemblyResolve += new ResolveEventHandler(MyResolveEventHandler);
Затем в методе обработчика событий вы можете загрузить сборку, которую пытались разрешить с помощью одного из переопределений Assembly.Load, Assembly.LoadFrom, и вернуть ее из метода.
Обновлено:
Основываясь на вашей дополнительной информации, я думаю, что использование описанной выше техники, в частности, самостоятельное разрешение ссылок на сборку - единственный реальный подход, который будет работать без реструктуризации вашего приложения. Что это дает вам, так это то, что местоположение каждой сборки, которую не удается разрешить CLR, может быть определено и загружено вашим кодом во время выполнения ... Я использовал это в аналогичных ситуациях как для подключаемых архитектур, так и для целостности ссылки на сборку инструмент сканирования.
Я пробовал этот метод, и StackOverFlow снова и снова запрашивает одну и ту же сборку ...
Вы можете использовать элемент <codeBase> из файла конфигурации приложения. Подробнее о "Поиск сборки с помощью кодовых баз или проверки".
Well, the loaded assembly doesn't have an application configuration file.
Хорошо, если вы знаете конкретные папки во время выполнения, вы можете использовать Assembly.LoadFrom.
Первая ссылка дает «Тема больше не существует». Однако указание .Net 4.0 вызывает это: https://msdn.microsoft.com/en-us/library/15hyw9x3%28v=vs.100% 29.aspx
Хорошим примером этой техники является приложение LINQPad. Он поставляется как единый исполняемый файл, поэтому все библиотеки включены как встроенные ресурсы. См. albahari.com/nutshell/ch16.aspx для кода и linqpad.net/HowLINQPadWorks.aspx для понимания.