2013-10-15 4 views
0

Я поддерживаю элемент управления 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, потому что они зарегистрированы в реестре правильно?

Я вытаскиваю свои волосы, так как я не могу найти полезное руководство.

+0

ли DLL неявно загружен. Или вы вызываете LoadLibrary? Попробуйте отладить целевой процесс и посмотрите в окне вывода. Что там написано, когда код выполнен. – xMRi

+0

Спасибо xMRI: Обертка статически загружена его lib, я не использую LoadLibrary, оболочка, в свою очередь, имеет библиотеку классов в качестве ссылки. Отладка цели немного сложна, поскольку стороннее приложение установлено на удаленную машину (а не на нашу), к которой я обращаюсь удаленно. Нет никакого сбоя, поскольку он просто не загружает активный X, который он делает, как только я удалю экземпляр объекта шифрования (который является экземпляром, исходящим из обертки). – user2796104

+0

Это довольно нормально, Windows не имеет никакого смысла искать в каталоге, где расположен COM-сервер. Однако, если добавление каталога в путь не работает, у вас возникают проблемы с большим объемом. Вам понадобится ProcMon SysInterals, чтобы посмотреть, где Windows ищет DLL. –

ответ

0

Попробуйте скопировать файл WrapperSimpleAES.dll в каталог сторонних разработчиков.

+0

Спасибо thomiel: К сожалению, стороннее приложение - это приложение Java, создающее каталог в этом случае System32, где находится javaws.exe. – user2796104

0

Проблема заключается в том, что вы используете ActiveX Control при вызове LoadLibrary. COM разрешает необходимую DLL через записи реестра. Ваша проблема теперь в том, что, когда ваш код выполняет следующую необходимую DLL, не найден.

В качестве временного решения:

  1. Установите вторичный DLL в качестве нагрузки задержки. Таким образом, это не требуется, когда ваш ActiveX Control загружается.
  2. Когда ваш ActiveX нуждается во вторичной DLL, используйте GetDllDirectory, чтобы получить текущую настройку и сохранить ее.
  3. Теперь используйте SetDllDirectory для Пути вашего основного ActiveX.
  4. Выполните свой код. Задержка будет успешной.
  5. После вызова используйте SetDllDirectory для восстановления старых настроек.

НТН

+0

хотя я не знаю, почему ОС не находит DLL, когда каталог уже находится в переменной окружения Path, я применил параметр /DELAYLOAD:"SimpleAES.dll в проекте SimpleAESWrapper.dll, и я использовал функция SetDllDirectory перед созданием экземпляра объекта SimpleAESWrapper в моем ocx, но пока ничего не получилось. У меня сложилось впечатление, что dll уже загружена, прежде чем что-то делать. – user2796104

+0

Позвольте клиенту работать. Присоедините отладчик к проекту и посмотрите, что произойдет. Также вы можете отслеживать загрузку DLL-файлов. – xMRi

+0

Я думаю, что у меня есть справедливое представление о том, что происходит, я просто не знаю, почему: просто putt, рассмотрим exe, который загружает dll-оболочку (статически или задержка, не будет иметь значения), обертывая библиотеку классов C#, оболочка будет всегда найдется, но библиотека классов отсутствует, даже если она находится в той же папке, что и обертка. Если exe находится в другом каталоге, он сработает, если он находится в том же каталоге, в котором он работает. Недопустимая ссылка: как позволить оболочке загружать библиотеку классов C#? – user2796104