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

Question

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

В файле надстройки C ++ / CLI DLL ссылается на имя, поэтому приложение загрузит его оттуда. Однако .NET DLL, однако, предназначена только с DLL C ++ / CLI (в качестве управляемой ссылки), поэтому экспортируемые типы доступны. В этой настройке Howerver, приложение сбивает загрузку .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 (зондирующий элемент) или действительно путем сборки монтажа.