OPC Core Library Compliance|OPC UA Implementation: Stacks, Tools, and Samples|Forum|OPC Foundation

Avatar
Search
Forum Scope


Match



Forum Options



Minimum search word length is 3 characters - maximum search word length is 84 characters
Lost password?
sp_Feed sp_PrintTopic sp_TopicIcon
OPC Core Library Compliance
Avatar
Robert Amtfjord
Member
Members
Forum Posts: 8
Member Since:
01/25/2017
sp_UserOfflineSmall Offline
1
02/15/2017 - 05:36
sp_Permalink sp_Print

Im working with an OPC implementation. I need all dll's to be CLSCompliant. I notice that in the assembly (AssemblyInfo.cs) for UA Core Library the option is set to false [assembly: CLSCompliant(false)].

Is there a reason for that?

Avatar
Guest
Guests
2
02/15/2017 - 06:48
sp_Permalink sp_Print

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
Robert Amtfjord
Member
Members
Forum Posts: 8
Member Since:
01/25/2017
sp_UserOfflineSmall Offline
3
02/15/2017 - 08:22
sp_Permalink sp_Print

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
Guest
Guests
4
02/15/2017 - 10:12
sp_Permalink sp_Print

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
Zbynek Zahradnik
Member
Members
Forum Posts: 62
Member Since:
02/24/2014
sp_UserOfflineSmall Offline
5
02/19/2017 - 22:55
sp_Permalink sp_Print sp_EditHistory

(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.

Forum Timezone: America/Phoenix
Most Users Ever Online: 510
Currently Online:
Guest(s) 16
Currently Browsing this Page:
1 Guest(s)
Top Posters:
Forum Stats:
Groups: 2
Forums: 10
Topics: 1351
Posts: 4579