Hello.
I apologize for delayed replies.
One of the reasons is that I am kind of out of ideas what to do next, without a possiblity to reproduce and debug the problem and try various configuration changes.
Question: Do you intend just Read and Write functions (and possibly stay with synchronous), but no Subscribe?
The reason I am asking is that indeed, the failure has to do with the interface that is needed for asynchronous operations, and subscriptions. Our component currently requires this to work well, even if you do not actively use async reads/writes, or subscriptions. That's why the setting I recommended earlier (for using async only) has not helped. But, we may be able to modify the component so that the async/subscription support becomes "optional" on the server part, and an error would only be reported if your code actually tries to use these functions. Can you please comment on this.
Note 1: It is a new information for me that your application is in ASP (or ASP.NET). There are differences in behavior that show under the IIS environment. But if I understand correctly, you get the same problem in applications outside IIS as well, so the ASP/ASP.NET fact does not change a thing.
Note 2: You might be able to use QuickOPC-COM from within ASP.NET as well, though it is somewhat non-standard usage. It is a COM object that can be instantiated by .NET using Interop (in addition, we produce an Interop assembly for it, undocumented - you should be able to find it in the Interop folder of QuickOPC-COM).

When you compile the app, do you run it from within Visual Studio? If so, can you try simply launching the compiled EXE from the command prompt or Windows Explorer instead?

Thanks.
Is it valid to say that the problem then appears when the Siemens server is targeted, but does not appear with our simulation server?
Or is there an evidence to the contrary, either with our demo apps or with your own?
Thank you

Is your application set to target .NET Framework 4.0? If so, can you switch it to .NET Framework 3.5? (in Properties of the Project?)

Hello,
you can disable the use of async reads/writes on the client side (in our component) by a statement similar to this:


easyDAClient1.ClientMode.AllowAsynchronousMethod = false;


With regard to DCOM settings, it would be a complete miracle if everything worked "out of the box", just by accident, in a remote scenario. It is, in fact, a difficult task to configure it right even with good knowledge and experience, and users regularly struggle with properly configuring DCOM for OPC.
You can Google for 'OPC DCOM', or here are some useful links:

www.opcactivex.com/Support/Tut...
www.matrikonopc.com/dcom-confi...

I'm sure Siemens will also have a document for it.
Best regards