OPOS library v1.14 is not working as expected with x64 build of .net


We are using the OPOS drivers v 1.11 in our Desktop application and now migrating it to v 1.14. The application is working fine with the newer version on x86 architecture but when compiled to x64 , it throws a runtime error for class not registered. The exception is encountered on the very first attempt to initialize a new instance of the object class. When called for new instance,

oPOSPOSPrinter = new OPOSPOSPrinter();

The exception thrown is,

Message=Retrieving the COM class factory for component with CLSID {CCB90152-B81E-11D2-AB74-0040054C3719} failed due to the following error: 80040154 Class not registered (Exception from HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG)).

The dlls we are refencing here is a 32 bit version & our application is compiled on 64 bit.

We tried to register it via regsvr32 tool but then it throws an exception there as well.

enter image description here

We tried to manually add it to the registry but it didn’t helped.

We tried with both the versions, one from the default OPOS installation directory & another from the OposFor.Net folder in the same directory.

So, we would like to ask for a solution as to how to achieve this? We want to migrate our application on x64 architecture and support all the current functionality from the OPOS v 1.11 on OPOS v 1.14. Also, will there be a 64-bit version of the OPOS drivers available in near future?

System & App Info: OS: Windows 10 Pro IDE: VS 2017, .Net Version: .Net 4 + OPOS dll Version: 1.14.001

asked on Stack Overflow Feb 21, 2019 by Ajeet Yadav • edited Mar 3, 2019 by valiano

2 Answers


UnifiedPOS(including OPOS) specification supports only 32 bit.

Download the current version 1.14.1 of UnifiedPOS
Page A-1

The goals of OLE for Retail POS (or "OPOS") include:
- Defining an architecture for Win32-based POS device access.
- Defining a set of POS device interfaces sufficient to support a range of POSsolutions.

Page A-3

A CO is a standard ActiveX (that is, OLE 32-bit) Control that is invisible at runtime.

Common CO only supports 32 bit.
MCS: OPOS Common Control Objects - Current Version

I experimentally created Common CO that supports 64 bit, but this is informal.

If you use OPOS as a service object in POS for.NET, you need to operate it with 32 bit.

For 32 bit exe/dll which runs in 64 bit OS, corresponding registry data is separated under WOW6432Node in varius places.
However, some registries are separated by 64/32, some registries are linked with 64/32, and so on.

Although device vendors may support 64 bit independently, it is considered to be few.

The following suggestions are possible.

  1. Divide the application into two or more processes and link them through interprocess communication.
    Main application running at 64 bit process.
    I/O control(OPOS) application operating at 32 bit process.
  2. Use only vendor equipment and OPOS that independently support 64bit.
  3. Use 32 bit OPOS from a 64 bit application, using techniques such as those described in the comments.

In Addition:
Supplementary information on the method of "3." is as follows.

DLL Surrogates
DLL Server Requirements
Using the System-Supplied Surrogate
Writing a Custom Surrogate

Interfaces that aren't remotable (such as those for recent OCXs) will not work with the system surrogate. A custom surrogate could wrap the DLL's interfaces with its own implementation and use proxy/stub DLLs with a remotable IDL definition that would allow the interface to be remoted.

Accessing 32-bit DLLs from 64-bit code in StackOverflow Article
Accessing 32-bit DLLs from 64-bit code Original Article

How do I make COM Surrogate Multiple Instance?
Hosting a .NET DLL as an Out-Of-Process COM Server (EXE)
REGCLS Enumeration

answered on Stack Overflow Feb 21, 2019 by kunif • edited Feb 26, 2019 by kunif

64 Bit process cannot call a 32bit library directly in it's process. You need to have a different approach to talk to 32 Bit library.

  • Create a seperate 32 Bit exe which will be doing what you want to achieve using that 32 Bit library, and call that exe from your 64 Bit process and by passing the right parameters based on which you can identify the call and it's action and you can return the desired output to your process.
  • You can as well create a WebSocket based client/server application and can communicate with your 64 Bit process, which can be a much faster approach then a exe
  • Alternativly you can as well create a WCF service where you can use your 32 Bit dll and consume that WCF service in your 64 Bit Application and be done with that.

Note: If the communication need to happen on the same machine (means your 64 Bit application and 32 Bit library is going to be in the same machine) in this case first two options will be the best work with.

Hope this info helps and can help you procees further.

Happy Coding...

answered on Stack Overflow Mar 4, 2019 by Abhinaw Kaushik

User contributions licensed under CC BY-SA 3.0