As I said, I do not know whether running Mono + CLR in one process is possible, but I do not have information either way, so it remains an open question at the moment. Certain versions of .NET CLR can run side by side in one process, though.

Do you you still sell this product?

We sell the current version (5.35), but whoever buys the license gets automatically licensed for the previous versions as well.

Can we have a demo version of these products ?

I will send you the download link to an email you used to register with this forum.

What do you exactly mean by "32- and 64-bit consumers" ? 64-bit processes can use them ?

Yes. Both 32- and 64-bit native processes (or managed code calling out to native) can connect to COM components exposed by QuickOPC 5.23, because 1) the COM components run in a different process (which happens to be 32-bit but that makes no difference in this case), and 2) only COM automation interfaces (IDispatch and dual) are used, therefore the marshaling is provided by standard Microsoft proxies/stubs that are in place for both 32-bit and 64-bit worlds.

Best regards

Thank you for your interest in our products.

The C++ examples should build and run under 64 bits as well. Thanks for pointing out to us that the examples do not have a Win64 configuration "out of the box", we will address that in a future version.

I have doubts, however, about whether *your* scenario (if I understand it well) will work. It may work - but I am not sure, and it is up to you to try it out. The issue is that (at least in the current version), the COM objects of QuickOPC are implemented by exposing the .NET objects, therefore by using them you first load the CLR and the CLR then runs the .NET objects which then have wrappers on top of them that make them into (in-process) COM objects. Assuming that our stuff does not run under Mono (we have never tried), this scenario would only work if 1) what gets loaded by creating the COM objects will be the Microsoft CLR and not Mono, and 2) Mono and the Microsoft CLR will then happily coexist in one process. As I said, I have doubts about it.

In older versions of QuickOPC, the COM objects were independent of the .NET stuff, and ran as 32-bit Local Server (out-of-process), usable from both 32- and 64-bit consumers. We no longer support these older versions, though, and of course stuff is missing from them compared to the current version (specifically, no OPC UA there).

Best regards