CLS Compliance testing is useless

After reading Patrick Steele's blog about the failure of CLS Compliance testing in VB.NET, I thought he was wrong, because he uses UInt32 as type, which is a native system type (i.e. a .NET type: System.UInt32).

However, he was right. The C# compiler fails to compile a simple statement like (when CLS Compliance testing is turned on via an attribute): 

public System.UInt32 Test;

Correct behaviour of the C# compiler? No. The reason why the C# compiler makes a mistake here is that I use a .NET type, System.UInt32, which is available to any .NET language (it's in the .NET System namespace after all). Therefor, if I specify a public identifier with this type, no matter what language is consuming the type, it can use it. Proof of this is VB.NET, which lacks an unsigned integer type, but can perfectly work with System.UInt32. Also, why would System.UInt32 fail CLS Compliance, but would another value type like System.Data.SqlTypes.SqlString not fail CLS Compliance testing (although it exposes implicit operators not usable in VB.NET!) ?

So is CLS Compliance testing of any use? Not that I'm aware of. If native .NET types, located in the System namespace, can't be used as types for public identifiers (like parameters, properties, return values etc.), why are these types defined in the first place? Because apparently some languages can't use them, otherwise these native, .NET types wouldn't cause a CLS Compliance violation!

Microsoft: or come up with valid rules, founded on solid reasoning, for CLS Compliance testing or stop with the CLS Compliance testing altogether, since at the moment it cries fool when compiling perfect usable code.

The conclusion of Patrick's article shouldn't be: why doesn't the VB.NET compiler test correctly, but why does the C# compiler test incorrectly.

8 Comments

  • Well, the UInt32 structure exposes an uint member. All fine, but why isn't an Int64 used internally and externally?





    When you have these kind of types in your core library, you define more than 1 library and not one: the CLS compliant one and the non-CLS compliant one.





    It's also bogus testing. You test for type compliance, but what does that mean? Several types in the .NET library expose overloaded operators. These are PART OF the type. However, not usable in f.e. VB.NET.

  • It is fine to have non-cls compliant members, you just need to make sure that everything can be accomplished without them, just in case a language does not support one of your method signatures.





    IMO, VB does to much in the background and doesn't give enough control over this type of stuff. I would be wary of using it for such projects. Apparently, the MS guys didn't think VB should be used for creating CLS compliant programs either, or they would have supported the CLS compliant attribute... So, moral of the story, use C# if you are working projects where you are concerned about Types. VB.NET is very loose with them (I guess some people do actually consider that a "feature," but I'm not one of them :-) ).

  • 'a' language... I think that definition is too vague. 'a MS language' is better. After all, if I define a new language for .NET, and it doesn't support 64bit integers, it can't use a lot of code since Int64 is CLS compliant but not according to my new language. :)





    So, VB.NET apparently forced this uint != CLS Compliance crap to exist. How thoughtful.

  • Jesse,





    To be clear, yes, you can use non-CLS types in your application. However, if you want to be CLS compliant, you can't publically expose any of those types.

  • Then your language isn't CLS compliant :-). However, just because it didn't have a "long int" or some language specific version of int 64 doesn't mean it wouldn't work. It should be able to use Int64 directly if it supports even the most basic type stuff from the CLI.

  • Frans,





    VB.NET really can't use unsigned ints. Sure, you can define vars of type UInt32, but once you try and do any operations with them (adds, substracts, even assignement) VB.NET complains because it doesn't know how to convert 'ints' to 'uints'.

  • Patrick, as long as you have CLS compliant ways to do everything, it doesn't matter much whether the rest is fully compliant (IMO). CLS compliance is a good test to make sure you won't run into any hairy situations, but I don't see any reason to force yourself to ONLY use CLS specific stuff if you run into a situtation where it makes sense to do otherwise.

  • Jesse, I think we're in agreement on this stuff.





    I think CLS-compliance really only needs to be achieved by component/tool authors. If you're just coding an internal application or something simple for yourself, who cares about CLS-compliance? It's only an issue if you want to make a library or utility that will want to integrate with another .NET language.

Comments have been disabled for this content.