Библиотека OPOS v1.14 не работает должным образом со сборкой xnet.net

Question

Мы используем драйверы OPOS v 1.11 в нашем настольном приложении и теперь переносим его на v 1.14. Приложение отлично работает с более новой версией архитектуры x86, но при компиляции в x64 выдает ошибку времени выполнения для незарегистрированного класса. Исключение встречается при самой первой попытке инициализации нового экземпляра класса объекта. Когда вызвано для нового экземпляра,

oPOSPOSPrinter = новый OPOSPOSPrinter();

Исключение -

System.Runtime.InteropServices.COMException HResult=0x80040154 Сообщение = Получение фабрики классов COM для компонента с CLSID {CCB90152-B81E-11D2-AB74-0040054C3719} не удалось из-за следующей ошибки: 80040154 Класс не зарегистрирован (исключение из HRESULT: 0x80001 REGDB_E_CLASSNOTREG)). Источник =mscorlib

DLL-файлы, которые мы здесь приводим, являются 32-битной версией, а наше приложение скомпилировано на 64-битной.

Мы попытались зарегистрировать его с помощью инструмента regsvr32, но затем оно также выдает исключение.

введите описание изображения здесь

Мы пытались вручную добавить его в реестр, но это не помогло.

Мы попытались использовать обе версии: одну из каталога установки OPOS по умолчанию и другую из папки OposFor.Net в том же каталоге.

Итак, мы хотели бы спросить решение о том, как этого добиться? Мы хотим перенести наше приложение на архитектуру x64 и поддерживать все текущие функциональные возможности из OPOS v 1.11 в OPOS v 1.14. Кроме того, будет ли доступна 64-разрядная версия драйверов OPOS в ближайшем будущем?

Информация о системе и приложении: ОС: Windows 10 Pro IDE: VS 2017, версия.Net: .Net 4 + версия OPOS dll: 1.14.001

Answer 1

Спецификация UnifiedPOS(включая OPOS) поддерживает только 32 бит.

Загрузите текущую версию 1.14.1 UnifiedPOS
Страница А-1

Цели OLE для Retail POS (или "OPOS") включают в себя:
- Определение архитектуры для доступа к POS-устройствам на основе Win32.
- Определение набора интерфейсов POS-устройств, достаточных для поддержки ряда POS-решений.

Страница А-3

CO - это стандартный ActiveX (то есть OLE 32-битный) элемент управления, который невидим во время выполнения.

Common CO поддерживает только 32 бит.
MCS: Общие объекты управления OPOS - текущая версия

Я экспериментально создал Common CO, который поддерживает 64 бит, но это неформально.
kunif / ОПОС-ССО

Если вы используете OPOS в качестве объекта службы в POS для.NET, вам нужно использовать его с 32-разрядной версией.

Для 32-битного exe/dll, который работает в 64-битной ОС, соответствующие данные реестра разделены под WOW6432Node в разных местах.
Однако некоторые реестры разделены на 64/32, некоторые реестры связаны с 64/32 и т. Д.

Несмотря на то, что производители устройств могут поддерживать 64-битную систему независимо, считается, что она немногочисленна.

Возможны следующие предложения.

1. Разделите приложение на два или более процессов и свяжите их посредством межпроцессного взаимодействия.
   Основное приложение, запущенное в 64-битном процессе.
   Приложение управления вводом / выводом (OPOS), работающее в 32-битном процессе.
2. Используйте только оборудование поставщика и OPOS, которые независимо поддерживают 64-битную версию.
3. Используйте 32-битный OPOS из 64-битного приложения, используя методы, подобные описанным в комментариях.

---

К тому же:
Дополнительная информация о методе "3". как следует.

DLL суррогаты
Требования к серверу DLL
Использование системного суррогата
Написание пользовательского суррогата

Интерфейсы, которые не являются удаленными (например, интерфейсы для последних OCX), не будут работать с суррогатом системы. Пользовательский суррогат может обернуть интерфейсы библиотеки DLL своей собственной реализацией и использовать DLL прокси / заглушки с удаленным определением IDL, которое позволит удаленному интерфейсу.

Доступ к 32-битным DLL из 64-битного кода в статье Stackru
Доступ к 32-битным DLL из 64-битного кода

Как мне сделать COM-суррогатный множественный экземпляр?
Размещение библиотеки.NET DLL в качестве внепроцессного COM-сервера (EXE)
DllSurrogate
Перечисление REGCLS

Answer 2

64-битный процесс не может напрямую вызывать 32-битную библиотеку в своем процессе. У вас должен быть другой подход для общения с 32-битной библиотекой.

• Создайте отдельный 32-битный exe-файл, который будет делать то, что вы хотите достичь, используя эту 32-битную библиотеку, и вызывайте этот exe-файл из вашего 64-битного процесса и передавая правильные параметры, на основе которых вы можете идентифицировать вызов и его действие, и вы можете верните желаемый результат в ваш процесс.
• Вы также можете создавать клиент-серверное приложение на основе WebSocket и взаимодействовать с вашим 64-битным процессом, который может быть намного быстрее, чем исполняемый файл.
• В качестве альтернативы вы также можете создать службу WCF, в которой вы сможете использовать 32-битную DLL и использовать эту службу WCF в своем 64-битном приложении и покончить с этим.

Примечание. Если обмен данными должен происходить на одном и том же компьютере (значит, ваше 64-битное приложение и 32-битная библиотека будут находиться на одном и том же компьютере), в этом случае лучше всего будут работать первые два варианта.

Надеюсь, что эта информация помогает и может помочь вам в дальнейшем.

Удачного кодирования...