2015-09-10 4 views
0

Я рассматривал проблему, связанную с модульным тестированием и управляемым/встроенным взаимодействием через C++/CLI. Детали не важны, поэтому я не буду заполнять их, если не будет задано, но ситуация может быть перегоняна следующим образом:Поведение по положению с зависимостями по положению при сборке по умолчанию AppDomain vs new AppDomain

Две сборки, назовите их Lib и Dep, существуют в том же каталоге, назовите это D. Lib зависит от Dep через ссылку на сборку. Мы работаем в приложении, которое живет в другом, несвязаном каталоге. Приложение создает новый AppDomain с ApplicationBase, установленным в каталог D, загружает сборку Lib и пытается построить в ней тип посредством отражения.

Как часть конструктора модуля Lib, мы переходим к стандарту AppDomain и загружаем ссылочную сборку. Поскольку ApplicationBase по умолчанию AppDomain не является каталогом D, Dep не может быть разрешен, генерируется исключение FileNotFoundException, и загрузка сборки Lib не выполняется.

Все это имеет смысл - как бы то ни было, мы попытались загрузить сборку, которая не находится на пути разрешения сборки для текущего AppDomain, и не удалось.

НО, если я запустил весь этот процесс в AppDomain по умолчанию вместо создания нового AppDomain, нет сбоя. Даже через каталог D не является ApplicationBase, сборка Lib загружается и код, создающий экземпляр одного из его классов, выполняется правильно. Код конструктора модулей все равно должен выполняться в AppDomain по умолчанию, хотя ему не нужно переходить на него.

Мне кажется, что второй случай должен потерпеть неудачу точно так же, как первый. Какая разница в процессе эталонного разрешения сборки между этими двумя случаями?

+0

Используйте Fuslogvw.exe чтобы получить представление. Записывать все привязки. –

+0

Отличное предложение, спасибо, что указали мне на эту утилиту. Я проверю его и отчитаю. – rationull

+0

Мне не удалось получить что-нибудь полезное из журнала Fusion. Для сборки Dep нет никаких записей журнала в случае успеха или сбоя. В записи журнала для сборки Lib есть некоторый контент в случае успеха, но в случае сбоя он, похоже, вышел из строя довольно рано в процессе, вероятно, из-за сбоя фактической загрузки. Хотя я ожидал увидеть хотя бы что-то для самой неудачной сборки, которая могла бы дать некоторое представление. – rationull

ответ

0

ОК, я нашел то, чего мне не хватало, прежде чем более полно читать the MSDN page "How the Runtime Locates Assemblies", чем раньше. В последнем разделе «Other Locations Probed» указывается, что при разрешении ссылок на загружаемую сборку местоположение загруженной сборки принимается за подсказку, где можно найти ссылочную сборку.

Основываясь на поведении, которое я вижу, я думаю, что мы можем экстраполировать информацию о подсказках, специфичную для AppDomain, так что подсказка не учитывается вне AppDomain, которая вызвала исходную загрузку сборки.

Я проверил это с помощью моего тестового проекта - если ссылочная сборка не переключается на AppDomain по умолчанию, тогда она загружается правильно. Таким образом, это не по умолчанию специальное поведение AppDomain, это общее поведение, ограниченное AppDomain.