Указание COM-объекта, запускаемого из местоположения

Я потянул за это свои волосы. У меня есть драйвер C++ OPOS, который я написал. Я написал в C# виртуальный пинпад. Работает и все хорошо.

Один запрос, который был дан мне, заключается в том, что драйвер C# должен присутствовать в вызывающей программе. Потребовалось некоторое время, чтобы понять, как мы ожидали, что он должен быть там, где находится драйвер OPOS. Заставляет меня думать, что я что-то не так настраивал.

Я знаю, что это расплывчато, и что требуется больше информации, но я не знаю, с чего начать или какую информацию вам нужно помочь в этом отношении. Я буду часто проверять и отвечать на любые вопросы.... тьфу, я ненавижу быть таким расплывчатым.. пожалуйста, не плачь:) Я буду редактировать столько, сколько нужно.

РЕДАКТИРОВАТЬ

Извините, что не очень хорошо сформулировал это. У меня было много всего, когда я писал это. Я перечитал это сам и думал "NEWB!" га.

Хорошо, так внизу и грязно. Вопрос не в драйвере COM, а в виртуальной клавиатуре C#. Подводя итог, я собираюсь сказать, почему мой dll C# virtual pinpad должен находиться в том же месте, что и мой исполняемый файл, а не в том же месте, что и мой зарегистрированный драйвер UPOS?

Так что, чтобы уточнить это. Драйвер работает (при условии, что я не испортил его снова). Как было указано, для любой программы его необходимо зарегистрировать. Все это хорошо во благо. Мы помещаем все необходимые файлы, связанные с этим драйвером UPOS, в одну папку. В какой-то момент у нас была виртуальная клавиатура C++, встроенная в драйвер UPOS, но для простоты я решил, что будет проще и быстрее создать виртуальную панель ввода C#, видимую для COM. И по большей части это было. Это было хорошо, потому что, если бы я сделал какие-либо графические изменения, я мог бы просто заменить VPP.dll, и жизнь была хорошей. Затем я установил этот набор драйверов на компьютер, и при попытке открыть VPP произойдет сбой. В отчаянии я начал копировать файл VPP.dll в разные места и обнаружил, что когда я помещаю его в то же место, что и моя исполняемая программа, он начинает работать. Это не то, что я хочу. Я хочу иметь возможность поместить его в тот же каталог, что и остальные мои драйверы. (Это зависит от среды, но в целом находится в папке "Program Files"). Это возвращает меня к моему обобщенному вопросу выше. Меня поражает, что мой драйвер UPOS - тот, кто делает COM-вызов. Когда я выполняю установку, часть моей установки - поместить файл VPP.dll в папку Program Files и запустить на нем regasm (что говорит об успешности). Так что я просто поражаюсь, что это должно быть с исполняющей программой. Да, и еще одна причина, по которой он должен находиться в централизованном месте, заключается в том, что у нас есть несколько разных программ (4, если быть точным), установленных в разных местах. И человеческая ошибка в том, что я не хочу копировать VPP.dll в потенциально 4 места на каждом компьютере. (что в итоге составит около 500)

так что теперь, когда я уточнил (и на самом деле задал вопрос.. извините), у нас есть какие-нибудь предложения?

2 ответа

Решение

Такая проблема является естественным следствием того, как Windows (или CLR, неясно) находит зависимые библиотеки DLL. Регистрация для COM-сервера предоставляет только путь к DLL, которая реализует сервер. В противном случае это не влияет на путь поиска зависимых библиотек DLL.

Если это встроенная (не.NET) DLL, то Windows выполняет поиск:

  • Каталог, из которого был загружен EXE
  • Опционально, каталог, указанный при вызове SetDllDirectory()
  • Системный каталог Windows, по умолчанию это c:\windows\system32
  • 16-битная устаревшая системная директория, по умолчанию c: \ windows \ system
  • Каталог Windows, по умолчанию это c: \ windows
  • Рабочий каталог по умолчанию для процесса
  • Каталоги, перечисленные в переменной среды PATH

Если это.NET DLL, то CLR ищет:

  • GAC
  • Каталог, из которого был загружен EXE
  • При желании путь зондирования, указанный <probing> элемент в файле app.exe.config.

Очевидно, что у вас не возникнет проблем, если зависимые библиотеки DLL будут расположены в каталоге EXE. И довольно неприятный, если вы хотите его где-то еще. Выберите один из приведенных выше списков.

Итак, у вас есть DLL (сборка.net), которая реализует интерфейс OPOS. OPOS-интерфейс по спецификации является COM-объектом (OPOS означает Ole для POS).

Я подозреваю, что это ваше требование: Приложения, использующие ваш драйвер, будь то встроенный или управляемый, должны иметь возможность создавать экземпляр вашего объекта через CoCreateInstance. Для этого ваше устройство должно быть зарегистрировано в реестре Windows. Смотрите пример ниже, чтобы узнать, как это сделать:

Примечание: вы должны знать, что был разработан более новый стандарт UPOS (Universal POS), и Microsoft ".NET для POS" имеет его поддержку, которая также обратно совместима с OPOS.

РЕДАКТИРОВАТЬ (следующие изменения в вопросах):
Таким образом, кажется, что ваш VPP является COM-объектом, и у вас есть программа, регистрирующая его таким образом, что он может быть CoCreatable из любой папки, которая не является текущей директорией. Я подозреваю, что что-то не так с его регистрацией. Убедитесь, что ваш COM-объект имеет идентификатор Porgram ID и уникальный CLSID. Оформить заказ в реестре как HKCR\CLSID\<your object class id&> так же как HKCR\<your object progid>, Держите UPOS и приложение в стороне на минуту. Просто убедитесь, что это простой файл JavaScript (xxx.js) со строкой: var x = new ActiveXObject(<your prog id>) будет работать при выполнении скрипта из любой папки.

Другие вопросы по тегам