What could go wrong if we don't use CLS?

Question

I'm writing a framework, and we want it to be available from C#,C++, VB. We are not stricted to any other languages for now. But we have some problems in using CLS (we have to use unsign's etc.). Can you give some real problems that appear if we are not using CLS here?

Answer 1

It's generally considered good practice to mark the assembly as CLSCompliant, then use the CLSCompliant(false) attribute on Types and Members that are not CLS-compliant.

Of course if the majority of types in your assembly are not CLS-compliant, it probably makes more sense to mark the assembly as non-compliant.

One way to minimize problems with other languages is to mark only individual members with CLSCompliant(false), and provide CLS-compliant alternatives for each such member.

Answer 2

Well, there are a lot of rules about CLS Compliance, not just ones regarding signed/unsigned types. One simple one which you'll have to follow or you already have problems is:

For two identifiers to be considered distinct, they must differ by more than just their case.

You don't need that for C# or C++, but Visual Basic requires that to be so. You also used the words "any other languages for now". If there's any possibility the list will expand in the future, you'll save yourself a lot of issues if you force yourself down the CLS Compliant road now.

Answer 3

The CLS defines a subset of features that are available in any language that is CLS compliant. Some exotic features, like unsigned primitive types, are excluded to make it easier for a language to meat the CLS.

As long as the languages that you are going to use supports the data types that you want to use, the code doesn't really need to be CLS compliant. If you want to be able to mark the code as CLS compliant anyway, you simply can't use the types that are not supported.

In some cases you can use a larger data type to handle unsigned values, for example use an Int64 to hold any value that an UInt32 could.