Practical limitations with assemblies not marked as CLS compliant?

Question

As an OSS library author, I've always tried to make my stuff CLS compliant. But MS doesn't make this easy. They often put you in catch-22 situations, such as the following:

• You cannot have a protected variable differing only in case from the public property.
• You cannot have protected or public variables starting in an underscore or 'm_'.
• If you want to make a class really extensible, you often need to have protected variables matching public properties. Your least ugly exit is to add a suffix to the variable, like "Var" or "Value". That's nasty and unacceptable to me. I like clean code.

I know of no .NET languages that don't support variables starting in an underscore, and I've used them in many places where the variable needs to be visible to subclasses.

I'm tired of the warnings, and I'm planning on turning off CLS compliance at the assembly level on my 30+ C# libraries.

Are there any actual problems with turning off CLS compliance on libraries? Any real problems with doing this?

Microsoft has issued unheedable guidance on software for decades, with less that 5% of it being worth the bytes it was encoded in. I can't find any evidence that this best practice has any real effect on anything.

But, to be careful, I'm checking.

And no, this is not a duplicate of the inverse of this question: Any reason not to mark a DLL as CLSCompliant?

I'm looking for actual results and effects here, not the advice of a MS intern.

For example, if IronPython, IronRuby, or F# are unable to read or write a variable starting with an underscore, that's an effect, although it would only cause a problem for users subclassing certain objects.

If a language or tool is completely unable to use an assembly unless it is marked CLS compliant, now that's a big deal.

Answer 1

From what I can tell, an actual or real problem with non-compliance is you lose the guarantee.

http://msdn.microsoft.com/en-us/library/bhc3fa7f.aspx

It's like overclocking your computer or driving your car with a third party mod on it, you lose "official" support from the people originally supplying you if anything goes wrong (even if it happens to work).

In the case of CLS compliance, you lose support from MS about the interoperability of your code against other languages (my own emphasis):

If you design a CLS–compliant class library, your library will have a guarantee of interoperability with a wide range of programming languages

As for all the catch-22s, I've no idea. Can't say I've ever cared about CLS compliance.

Answer 2

About the problem you used as an example:

• If the public property has a public setter and getter, the protected variable is not needed, because derived classes can set the value using the public property.
• If the public property doesn't have a public setter, give it a protected setter. This removes the need for a protected variable, because derived classes can set the value using the protected setter of the public property.
• Public variables should be avoided completely.

Conclusion: There is normally no need for protected or even public variables. It can all be modeled using properties.