Я поддерживаю элемент управления ActiveX, разработанный в MFC, который будет использоваться в качестве плагина для нескольких коммерческих приложений. Все это работало отлично, пока я не хотел, чтобы шифрование AES включалось, потому что элементу управления необходимо автоматически войти в удаленное местоположение. Неважно, создана библиотека классов C# (SimpleAES.dll), которая предоставляет только класс с двумя членами, шифрование и дешифрование. Смешивая управляемый и неуправляемый код, я написал библиотеку-оболочку в C++/CLR, завершающую мой класс шифрования (SimpleAESWrapper.dll).ActiveX не загружает библиотеку, даже если она находится в том же месте.
Это все работает как прелесть при тестировании с использованием моего приложения-контейнера ocx, сохраняя все 3 библиотеки в том же каталоге, что и тестовое приложение-контейнер (то есть test.exe вместе с ocx вместе с двумя dll-файлами).
К сожалению, когда я запускаю приложение стороннего производителя, которое загружает ocx, ocx не загружается, поскольку он вызывает сбой, как только я создаю экземпляр класса шифрования из-за того, что он не может найти WrapperSimpleAES. длл. Приложение третьей стороны запускается из другого места. Добавление расположения библиотек в путь или даже в папку system32 не решает проблему.
Я пропустил что-то важное, как, например, библиотеки должны быть зарегистрированы каким-то образом, как в ocx с regsvr32.exe? Например, приложения знают, где найти ocx, потому что они зарегистрированы в реестре правильно?
Я вытаскиваю свои волосы, так как я не могу найти полезное руководство.
ли DLL неявно загружен. Или вы вызываете LoadLibrary? Попробуйте отладить целевой процесс и посмотрите в окне вывода. Что там написано, когда код выполнен. – xMRi
Спасибо xMRI: Обертка статически загружена его lib, я не использую LoadLibrary, оболочка, в свою очередь, имеет библиотеку классов в качестве ссылки. Отладка цели немного сложна, поскольку стороннее приложение установлено на удаленную машину (а не на нашу), к которой я обращаюсь удаленно. Нет никакого сбоя, поскольку он просто не загружает активный X, который он делает, как только я удалю экземпляр объекта шифрования (который является экземпляром, исходящим из обертки). – user2796104
Это довольно нормально, Windows не имеет никакого смысла искать в каталоге, где расположен COM-сервер. Однако, если добавление каталога в путь не работает, у вас возникают проблемы с большим объемом. Вам понадобится ProcMon SysInterals, чтобы посмотреть, где Windows ищет DLL. –