Actually the file contains the serialized data, but I was able to make use of it anyway. And, the serialization does not contain any references to the Opc.Ua.Core assembly - so my suspicion in this respect was incorrect.

My understanding is that the problem is resolved. I think we can conclude that the binary (de)serializer simply behaves that way - it somehow does not go through the assembly loading mechanism we have for the embedded assemblies, making it necessary to explicitly add or reference them - even if they are not truly needed.

Best regards

Can you please attach the file?

Oh, I see what you mean - OPC Unified Architecture .NET Standard 1.4.360.0 is installed because we have a single NuGet package and it is needed under .NET Standard. But it does not get used, in fact, when you target .NET Framework. That should be OK.

If the serialized data contained any data types from the Opc.Ua.Core assembly, I would not be surprised that the deserialization can have problems. This is because, as I wrote, the Opc.Ua.Core assembly is embedded inside QuickOPC and resolved dynamically, and I can imagine that for some reason the binary deserializer does not go through that resolution process. A fix to this would probably be to place/deploy the embedded assemblies (that you normally do not see) alongside your other binaries, in the directory where they run. Please see opclabs.doc-that.com/files/onlinedocs/QuickOpc/Latest/User%2...webframe.html#Assemblies2.html - you'd need to run the Setup program with "Custom" type and select "Embedded assemblies" to obtain the files.

Even if the above works, it would still not be clear why any type from Opc.Ua.Core is in your UAEventData.

Do you get the problem with any UAEventData you have, or just with some?
Can you somehow print out/display what you have in the UAEventData that has the problem, before serialization, and post it here?

Thank you

For .NET Framework target, QuickOPC 2020.2 (i.e. 5.58) is based on OPC Foundation's UA-.NET-Legacy libraries as of March 25, 2020, which are labeled as version 1.3.342.0. The fact that an assembly with that version is (indirectly) referenced is therefore no surprise.

For ease of deployment, these assemblies are embedded inside OpcLabs.EasyOpcUA assembly, so you don't normally get to see them.

What s not clear is why a reference to that assembly would appear inside the serialized data, or would otherwise be needed during deserialization. That should not be the case under normal circumstances.

I do not understand why, in your first post, you wrote
"OPC Unified Architecture .NET Standard 1.4.360.0 (NuGet)".

1. Is that a package you are referencing?
2. If so, why?
3. Are you running your project under .NET Framework, or .NET Core, or sometimes the first and sometimes the second?

Thank you