Я рассматривал проблему, связанную с модульным тестированием и управляемым/встроенным взаимодействием через 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 по умолчанию, хотя ему не нужно переходить на него.
Мне кажется, что второй случай должен потерпеть неудачу точно так же, как первый. Какая разница в процессе эталонного разрешения сборки между этими двумя случаями?
Используйте Fuslogvw.exe чтобы получить представление. Записывать все привязки. –
Отличное предложение, спасибо, что указали мне на эту утилиту. Я проверю его и отчитаю. – rationull
Мне не удалось получить что-нибудь полезное из журнала Fusion. Для сборки Dep нет никаких записей журнала в случае успеха или сбоя. В записи журнала для сборки Lib есть некоторый контент в случае успеха, но в случае сбоя он, похоже, вышел из строя довольно рано в процессе, вероятно, из-за сбоя фактической загрузки. Хотя я ожидал увидеть хотя бы что-то для самой неудачной сборки, которая могла бы дать некоторое представление. – rationull