Ссылка на сборку не найдена, хотя сборка находится в том же каталоге

Question

В настоящее время мы разрабатываем надстройку для некоторого программного обеспечения.Мы решили разрабатывать в .NET, хотя приложение написано на каком-то родном языке.Поскольку при создании внешнего интерфейса в .NET возникали некоторые проблемы, мы решили создать DLL-библиотеку моста в C ++ / CLI, которая выполняет некоторую базовую инициализацию, а затем загружает нашу управляемую сборку и создает из нее пользовательский элемент управления.* В файле надстройки .ini на DLL C ++ / CLI ссылается по имени, поэтому приложение будет загружать ее оттуда.На DLL-библиотеку .NET, однако, ссылаются только на DLL-библиотеку C ++ / CLI (в качестве управляемой ссылки), поэтому экспортируемые типы доступны.В этой настройке, однако, приложение аварийно завершает загрузку .NET DLL.

Мы быстро обнаружили, что можем просто подписаться на событие AppDomain.AssemblyResolve для загрузки сборки .NET из того же каталога, где находится C ++ / CLI.DLL есть, поэтому сама проблема решена.

Фактический вопрос: почему загрузчик не находит .NET DLL, даже если он находится в том же каталоге, что и сборка, на которую он ссылается?Я всегда ожидал, что загрузочные сборки будут сначала смотреть в один и тот же каталог, а не только в текущий рабочий каталог.Почему исполняемый файл находит сборку, если он меняет свой рабочий каталог?Или все по-другому, если CLR вызывается загрузкой сборки C ++ / CLI (а не чисто управляемого приложения)?

Answer 1

Я бы порекомендовал вам использовать fuslogvw.exe для анализа проблем такого рода:

Fuslogvw.exe и диагностика проблем с привязкой сборки .NET

И, конечно же, универсальный инструмент для анализа проблем с файлами не найден:

Монитор процесса

Answer 2

Путь поиска для сборок становится немного непредсказуемым, когда неуправляемый EXE запускает процесс. Только то, что он загружал C ++ / CLI DLL, возможно, через LoadLibrary или SetDllDirectory, не никак не влияет на путь поиска для CLR.

Но это только догадки. Нет необходимости угадывать, когда вы смотрите на вывод, созданный Fuslogvw.exe. Он показывает вам, что именно проверяется и какие политики применяются. Вы исправили проблему с помощью файла app.exe.config (элемент исследования) или даже с помощью AssemblyResolve.