Visual Studio is not needed to run C# build, just to build them.

I appreciate that you have given me a global view. Here it is from my side: It is possible that the problem you have has been fixed in the version that we have in development. The changes in this area were, however, rather big, and therefore the same changes won't be ever made back to the current version. The new version (5.40) should be released in 1-2 months, but we have an Alpha of it already. If you are interested, I can send you a link to it privately. If that works, and if you can then wait for the release, fine. Otherwise, I am afraid I cannot help you more at the moment.

Best regards

.NET Framework does not get "compiled into" the application. It must be installed on the target machine, and the .NET applications (including QuickOPC, event though in the end it behaves like a COM component) just make use of it.

For this reason, Visual Studio does not have to be installed in order to figure out the .NET Framework versions. What I need is 1) the operating system version, and 2) any installed .NET Framework version from the Control Panel (Programs). And, compare that between machines A) and .

For the same reason, it is clear that EasyOpcUADemo doesn't work either on the problematic machine. This shows that there is nothing wrong with your app, it is how I suspected - something gets wrong between our component and the system or .NET Framework on machine A.

Best regards

Thank you - I understand now. I think that this further supports the point that the issue is not in the fact that a local server is being addressed; the issue is simply in some kind of "misunderstanding" between our component and the machine it is installed on. It would be interesting to compare the versions of .NET Framework on A and B - can you do that?

And, can you please try the following: Set certain parameters (that are otherwise determined automatically) from the code. The precise values do not matter that match. At the very of you application, instantiate the EasyUAClientConfiguration object, and set

.SharedParameters.Engine.ApplicationCertificateSubject = ...
.SharedParameters.Engine.ApplicationName = ...
.SharedParameters.Engine.ApplicationUriString = ...
.SharedParameters.Engine.ProductUriString = ...

There is a chance - not a big chance, but still a chance - that this will resolve the problem.

Best regards

Sorry for overlooking that.
Note that ZIP files should be uploadable to these forums just fine. I do not know why you are renaming them to TXT.

I doubt that the problem has to do with whether the server is local or remote, because the log indicates issues that appear before any processing of the server URL even occurs. Is everything else the same? Isn't it so that you are using a different computer to run the working and non-working app?

Anyway, the issue appears to have to with the way the client certificate are being determined. We were fixing something in this area for the upcoming version, but that will not be release soon. I will check whether there is some workaround. Please expect further post here later.

Best regards