Actually, both of these are explainable.

In my reply (in this forum thread) from 03 Mar 2015 14:45, I explained that there are two keep-alive mechanisms. Currently we are only trying to turn off one of them when we detect a debugger. I have made a note to address this, and add a similar handling for the second keep-alive mechanism in a future QuickOPC version.

And, your observation about a possible contention when accessing the server from the event handler is right. In principle some of this contention cannot be removed, therefore (until/if we decide to actually handle it for you and queue the events and call the handler from a separate worker thread) your idea to work around it is correct in principle.

Note, however, that Task Parallel Library (TPL), and thus Task.Run, is quite unpredictable in when it will run the task. This is OK for some application, but possibly a very unpleasant surprise in others. For example, we have seen it wait with execution and "stack" the work for extended periods of time, when it has observed certain pattern of incoming requests. It fully follows its "contract", i.e. in the end it *does* execute the task, but beside it, no assumptions about the timing should be made. Other means of doing it (e.g. plain .NET threads) are of course still non-deterministic due to the nature of Windows scheduling, but still far better predictable. Just a hint...

If the error you are getting is still the same (indicating a problem with the "hashsize" argument for the certificate generator), then I still believe the cause must be a mismatch in the versions.

When we install fresh QuickOPC 5.32 (note that the version is relevant here - I understand that 5.32 is what you are using now), there is a file Opc.Ua.CertificateGenerator.exe under a folder similar to "C:\Program Files\Common Files\OPC Foundation\UA\v1.0\Bin" (it will be "Program Files (x86)" on 64-bit systems. The file must be precisely 1,149,760 bytes long, and I am attaching it (zipped) to this post, for convenience.



The issue is not really related to certificate verification or trusting that you mentioned. I do not fully understand what you mean by:

Ok is there a way to autotrust anycert that is generated.

I do not want my application failing because of the certificate not being confirmed as trusted.

The certificate being generated on the client side is presented to the server, and verified there. If you want that the servers trust it, or that it trust any client certificate, you need to arrange it on the server side, for which please refer to the server documentation or seek help with the server vendor.

In the opposite direction, there is a verification of the server certificate on the client side. If you want your client to trust any server certificate, set AcceptAnyCertificate to 'true' in CertificateAcceptancePolicy, which for the EasyUAClient-s with Isolated = false (the default) is taken form the static EasyUAClient.AdaptablePArameters, whereas for EasyUAClient-s with Isolated = false it is taken from their instance's IsolatedParameters.

Turning off the certificate checks, be it on server or client side, is meant for testing purposes only. It invalidates much of the OPC UA security. I recommend against using it, outside of test environment.

Best regards

The certificate is always generated, even with security turned off. This behavior is by design (and for a reason).

The error occurs because an improper version of UA certificate generator exists where the component is looking for it. Try reinstalling the "OPC UA Local Discovery Server 1.02" from the Redist folder in QuickOPC installation directory.

On a relation between debugging, and slow-down with large number of exceptions or IntelliTrace, an interesting article: blogs.msdn.com/b/visualstudioalm/archive/2015/03/03/make-deb...faster-with-visual-studio.aspx .

Right now I cannot think of other legitimate reasons for BadSessionIdInvalid. It could be consequently related to the "publishing stopped" - i.e. the publishing stops first, then the session closing process is invoked. But I cannot be sure.

It may be worth to make another Wireshark capture with this issue, at this point.

I have to apologize in advance - between May 8 and May 20 I will be out of office with very limited access (and unfortunately there isn't another person to do this level of support).

Best regards