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