There is no "result" for it, because what we have inside QuickOPC are two versions of this internal assembly (which is written in C++/CLI): One compiled for 32 bits, and one for 64 bits. And, the upper level assembly (EasyOpcClassic) decides (dynamically, in runtime) which one of these two to load. So in theory, there would be some exception (quite different from inability to browse - something like "incorrect EXE format") if someone tried to load 32-bit DLL into 64-bit process or vice versa, but because of the logic in EasyOpcClassic assembly, this cannot happen, because the right version is always loaded.

Actually,

after inspecting the exception more closely, I could determine that your program is *not* a 32-bit application. It runs in a 64-bit process, because the assembly it came from is App_Web_OpcLabs.EasyOpcClassicRaw.amd64, and it is impossible for Windows to load this 64-bit DLL into a 32-bit process.

You have answered to: "4. Does your client run in 32-bit or 64-bit process?" by "64 bits".
Now you wrote "Our program that is using your component is a 32 bit application."

I think this is a contradiction. Can you please clarify that.

All .NET binaries that come with QuickOPC are compiled for "AnyCPU" target. That is, they run in 32-bit process on 32-bit systems, and in 64-bit process on 64-bit systems. Changing them to always run in 32-bit process is possible either by a) opening the corresponding example solution (because they come with source code), changing the target CPU in project properties, and rebuilding, or b) patching the existing binary using the CORFLAGS utility, docs.microsoft.com/en-us/dotnet/framework/tools/corflags-exe-corflags-conversion-tool .

Proper registration is a task for the server vendor. Windows normally "reflects" the corresponding parts of the registry between the 32- and 64-bit worlds, so the component vendors do not necessarily have to do anything special, but it does not always work. First we need to establish whether the following two facts are both true: 1) all 32-bit local clients work and 2) no 64-bit clients work.

Best regards

Can you please, for test, rebuild the client application to run under 32 bits (target CPU = x86)?
It is quite likely that the OPC server has not registered itself in 64-bit part of the registry.

(I assume all other OPC clients that you have tested actually run in 32-processes, right? Note: Task Manager can show this).

Best regards