![Avatar](https://opcfoundation.org/wp-content/uploads/sp-resources/forum-avatars/defaults/guestdefault.png)
Hello Robert,
The absence of CLSCompliant is because of the multi-platform nature of OPC UA and the extended set of data-types that are supported. By enabling CLS compliance the code would be unable to interoperate with other platforms that do support a larger set of data-types, such as unsigned integers.
Hopefully this document will help: https://msdn.microsoft.com/en-.....7a7h3.aspx
![Avatar](https://opcfoundation.org/wp-content/uploads/sp-resources/forum-avatars/defaults/userdefault.png)
01/25/2017
![sp_UserOfflineSmall](https://opcfoundation.org/wp-content/sp-resources/forum-themes/reboot/images/darkpack/sp_UserOfflineSmall.png)
Hello Nathan and thanks for the fast response.
Ok, then I understand.
In my case I'm trying to get the OPC Foundation OPC Client to work together as an integrated part with an existing platform. This other platform only accepts DLL-files that are CLS compliant.
If I understand you correct, I could switch on that CLS to true and it would work for my purpose (only communicating with a specific OPC server). But not with other platforms. Or do I need to change something more to get it work=
![Avatar](https://opcfoundation.org/wp-content/uploads/sp-resources/forum-avatars/defaults/guestdefault.png)
Hello Robert,
Yes, by incorporating the CLS compliance you will potentially limit the interoperability with other UA enabled systems, meaning that there would be some data that you would not be able to work with. I haven't tried changing this so I don't know the expected outcome, although I can't help but wonder if you will need to create some kind of "wedge/gateway" to act as a broker.
![Avatar](https://opcfoundation.org/wp-content/uploads/sp-resources/forum-avatars/defaults/userdefault.png)
02/24/2014
![sp_UserOfflineSmall](https://opcfoundation.org/wp-content/sp-resources/forum-themes/reboot/images/darkpack/sp_UserOfflineSmall.png)
(Disclaimer: This is a self-promotion)
The QuickOPC client toolkit (http://www.opclabs.com/product.....chitecture ) is CLS compliant. This applies to the types of the toolkit itself, and to the actual OPC UA data being transferred.
For example, when the actual OPC UA data type is 16-bit unsigned integer (which is not CLS-compliant), we would return it as (CLS-compliant) 32-bit signed integer when reading and subscribing to. A conversion from a .NET type to actual OPC UA type also occurs during writing (in which case it gets a bit more complicated, but it is all handled internally to the component). More info: http://opclabs.doc-that.com/fi.....PC-UA.html .
When done in this way, the CLS compliance does not limit the OPC interoperability at all (as opposed to what Nathan suggested).
Note that just by switching on the attribute, you do not make an assembly CLS-compliant. This is just a declarative attribute that makes it easy for other tools to recognize the fact. In order to be CLS compliant, the types in the assembly actually need to conform to the CLS rules.
1 Guest(s)