CLS allows private portions of the code in classes to be non CLS compliant. How is this possible?

Question

CLS allows private portions of the code in classes to be non CLS compliant. How is this possible, because ultimately the code needs to be converted to the IL ?

Answer 1

CLS stands for Common Language Specification. To simplify, it's basically the minimal types and identifiers that all .NET languages must know about. For example, Int32 is CLS-compliant: any .NET language must be able to handle it. UInt32 is not. Since your code is private, it won't be accessed by other assemblies in other languages so it doesn't matter if it is CLS-compliant or not.

See this MSDN page for more information about CLS-compliance.

Edit: I think you misunderstand what CLS compliance is. It's not about whether the code can be compiled into IL or not. UInt32 can be used in IL. So does an identifier named '©'. CLS-compliance is just a minimal contract for language interoperability. What the CLR supports is way broader than the limitations for CLS compliance.

Edit2: Yes, you're right. A .NET language is required to support Int32, not UInt32, even if has a direct mapping to IL. See pointers, they're supported in IL and in C# but are not CLS compliant. VB.NET doesn't implement a support for them and still is CLS-compliant.

Answer 2

No - The CLR does not need to know what's happening under the hood. You need to have only your public classes and public/private members of those public classes to be CLS compliant, rest code will never be accessed - it will remain inaccessible to other languages that use your classes.