Thank you for the link.
I will let you know if I can do what I want with the previous version.

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

support wrote: Mono and the Microsoft CLR will then happily coexist in one process. As I said, I have doubts about it.

I didn't even imagine that one process could have two runtime engine running. Is it possible ? I think I have to try, as you said.

support wrote: 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).

Do you you still sell this product?
Can we have a demo version of these products ?
What do you exactly mean by "32- and 64-bit consumers" ? 64-bit processes can use them ?

Thank you for your helpful answer, anyway.
Antoine

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

Hello,
I would want to call QuickOPC API from a 64-bits C# process (Unity3D).
I can't use QuickOPC.NET because the C# process runs with Mono, which does not support DCOM.
Therefore, I have to make unmanaged C++ extern methods that I will call from a Unity3D C# script (with marshalling).
As far as I can see from your C++ samples, projects are only compiled for 32-bits. but I need these DLLs to be 64-bits to be called by Unity3D.
Is QuickOPC C++ samples 64-bits compliants ? Or is it just an omission in the samples ?

Best regards,
Antoine