Thank you.

In case your app is already 32-bit, I really do not know what the cause could be. I think it is probably something simple, but there are so many things to check that it cannot be done via "I ask you to check this, the customer checks that and explains the result" in a loop - that would take incredibly long.

Can't we get a temporary remote access to the machine, under their supervision (VNC or similar), to look around and investigate? Or, of course, if there is a way to install the server on our computer and it would exhibit the same behavior, we can do it as well - but need to get an operational server software for that.

Regards

Michael,

I do not understand how this reply relates to the problem reported. In fact, I hardly understand any piece of it.

This is my understanding of the issue we had: We were trying to address was the fact that QuickOPC could see the server, but was not able to browse its items or do read/writes etc. - it always ended up with "Class not registered".

My suggestion was to build your app for 32-bits only (x86 target CPU), because there is a high chance the server does not register itself well for the 64-bit world. There was no reply to this from your side, so I assume you have not tried.

I do not know what is the cache file they are referring to, or what they mean by "...the DeltaV server address, type and name had to be added manually to the cache.". Also it somewhat weird that the XML file refers to things like "XiServer" and "http://10.122.150.170:58080/xiservices/serverdiscovery". This seems to be related to the so-called OPC Express interfaces, latter dubbed Xi and latter dubbed OPC.NET, which is completely different from any other OPC spec, and was, at one time, forced by a big player onto OPC Foundation standardization committee and that, besides Emerson, practically nobody is using. QuickOPC does *not* support OPC Xi at all, and never will. It is a dead thing. But it is possible that the server supports OPC Xi and OPC DA at the same time. It is then, however, important not to mix their connection info. OPC Xi is basically a Web service interface (hence the "http:..." URL in their cache), while OPC DA is COM based and servers are identified by the (machine name and) ProgId/CLSID.

Best regards

I am not saying it should not be able to browse at all. I just want to get the facts first, and so far it does look the problem may have to do with the 64-bit-ness of your app - because it is, in fact, running in 64-bit process, and I have no indication that other servers are.

Before we start thinking about other possibilities, it is important to verify that the hypothesis (that is, it is the 64-bitness of the client that causes it) is correct. To do so, can you re-build your project to be strictly 32-bits (target x86 and not AnyCPU or x64), OR use the CORFLAGS on the EXE you already have to force it to 32 bits, and then retest to see whether the problem has disappeared?

Best regards

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.