c # — указание 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)

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

-1

Решение

Такая проблема является естественным следствием того, как 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. И довольно неприятный, если вы хотите его где-то еще. Выберите один из приведенных выше списков.

1

Другие решения

Итак, у вас есть 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>) будет работать при выполнении скрипта из любой папки.

1

По вопросам рекламы ammmcru@yandex.ru
Adblock
detector