CLS vs .NET type compliance: understanding the difference

Question

I'm missing something here. I get that one would use .NET compliant types in public interfaces and methods so that .NET languages can play nicely together (for example, "System.String", not C#'s "string").

If one uses .NET compliant types, then surely all .NET based languages can inter-operate. When and how does CLS compliance factor in?

For example, System.UInt16 is .NET-compliant, not CLR-compliant, and equivalent to "ushort" in C#.

Answer 1

I get that one would use .NET compliant types in public interfaces and methods so that .NET languages can play nicely together (for example, "System.String", not C#'s "string").

That is actually not an issue. Using C#'s string will result in exactly the same CIL as using System.String.

When and how does CLS compliance factor in?

Some languages do not support all types, so CLS compliance is required if you want to support the type system that is going to work cleanly in all languages. This means that ushort (System.UInt16) is not guaranteed to be usable by all .NET languages, so you should avoid exposing it in a public type if you want to be CLS compliant.

There are other rules you need to follow for CLS compliance, such as not differentiating members merely by case, as some languages are not case sensitive. The type requirements are merely one of many requirements for full CLS compliance.

The main issue here is that the common .NET languages (such as C#) allow you to use many types, names, and techniques that aren't guaranteed to be available to ALL CLS compliant languages - C# is more flexible than it a language needs to be for CLS compliant. This means that, when you use C# to write code, if you want that code to be usable by all CLS compliant languages, you need to restrict what you expose in public APIs.

Answer 2

CLS compliance is stricter than just the shared types system (meaning the types that all .NET language can use).

One example is naming - in C# you can start a public member name with an _.

This is not CLS compliant, as not all languages allow it.

Answer 3

If one uses .NET compliant types, then surely all .NET based languages can inter-operate.

That's not at all true. Not all languages support all of the .NET types. For example, earlier versions of VB.NET didn't support UInt16, UInt32, or UInt64.

When and how does CLS compliance factor in?

The CLS defines, among other things, the types that languages must implement in order to interoperate. All other types are optional.