Why Are Unsigned Int's Not Cls Compliant

Why are unsigned int's not CLS compliant?

Not all languages have the concept of unsigned ints. For example VB 6 had no concept of unsigned ints which I suspect drove the decision of the designers of VB7/7.1 not to implement as well (it's implemented now in VB8).

To quote:

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

The CLS was designed to be large enough to include the language
constructs that are commonly needed by developers, yet small enough
that most languages are able to support it. In addition, any language
construct that makes it impossible to rapidly verify the type safety
of code was excluded from the CLS so that all CLS-compliant languages
can produce verifiable code if they choose to do so.

Update: I did wonder about this some years back, and whilst I can't see why a UInt wouldn't be type safety verifiable, I guess the CLS guys had to have a cut off point somewhere as to what would be the baseline minimum number of value types supported. Also when you think about the longer term where more and more languages are being ported to the CLR why force them to implement unsigned ints to gain CLS compliance if there is absolutely no concept, ever?

.NET Framework: Argument type 'uint' is not CLS-compliant on P/Invoke

If you are not writing a component intended to be used by others in a different language, then you do not need to be CLS-compliant. Just declare that you are not (as you've already done).

However, it is possible to use uint internally and still provide a CLS compliant interface. Writing CLS-Compliant Code.

(link updated)

Why is this parameter not CLS-compliant?

My guess is that your C# library itself is not marked with CLSCompliant. I just duplicated the error, with the VB project marked CLSCompliant, and the C# library that it references is not marked CLSCompliant.

I marked the C# library CLSCompliant, and the warning went away.

Why does C# include programming constructs that are not CLS-compliant?

Even unsigned integers aren't compliant (at least, on the public API), yet they are very important to people who do bit-shifting, in particular when right-shifting (signed and unsigned have different right-shift behaviours).

They are ultimately there to give you the freedom to use them when appropriate. The case-sensitivity one I could get less religious about - despite the convenience of having a field and property differ only by case, I think I could live happily with being forced to use a different name! Especially now we have automatically implemented properties...

This is similar to how it lets you use unsafe - the difference here being that a few unsigned integers aren't going to destabilise the entire runtime, so they don't need quite as strong molly-guards.

You can add:

[assembly: CLSCompliant(true)]

if you like, and the compiler will tell you when you get it wrong.

And finally: most code (by volume) is not consumed as a component. It is written to do a job, and maybe consumed by other code in-house. It is mainly library writers / vendors that need to worry about things like CLS compliance. That is (by the numbers) the minority.

Why doesn't .NET use unsigned integer types for things like DateTime.Month and DateTime.Year?

To quote "Language Independence and Language-Independent Components"

The .NET Framework is language independent. This means that, as a developer, you can develop in one of the many languages that target the .NET Framework, such as C#, C++/CLI, Eiffel, F#, IronPython, IronRuby, PowerBuilder, Visual Basic, Visual COBOL, and Windows PowerShell. You can access the types and members of class libraries developed for the .NET Framework without having to know the language in which they were originally written and without having to follow any of the original language's conventions. If you are a component developer, your component can be accessed by any .NET Framework app regardless of its language.

Not all languages support unsigned integers, so because of that using unsigned integers in public or protected methods makes your code non CLS compliant. You are allowed to use them on private and internal members, just not on public or protected ones. Because of this the .NET framework tries to make all of it's public methods and members CLS compliant so they can be used from any language.

Why is this not cls-compliant?

The message is stating that the property's type is not compliant.

Check the MyBusinessObject class; many developers forgot to add [assembly: CLSCompliant(true)] (unfortunately, it isn't part of the standard template)

Why does .NET Framework not use unsigned data types?

Unsigned numeric types are not CLS compliant so they should not be used for any API - especially the .NET framework.

Basically, CLS compliant code only utilizes types that are available in all .NET languages. Some languages (like VB.NET) does not support unsigned numeric types.

---

Related Topics