Common Language Specification (CLS)

As you are aware, different languages express the same programming constructs in unique, language-
specific terms. For example, in C# you denote string concatenation using the plus operator
(+), while in VB .NET you typically make use of the ampersand (&). Even when two distinct languages
express the same programmatic idiom (e.g., a function with no return value), the chances
are very good that the syntax will appear quite different on the surface:
// C# method returning nothing.
public void MyMethod()
{
// Some interesting code...
}

' VB method returning nothing.
Public Sub MyMethod()
' Some interesting code...
End Sub
As you have already seen, these minor syntactic variations are inconsequential in the eyes of
the .NET runtime, given that the respective compilers (csc.exe or vbc.exe, in this case) emit a similar
set of CIL instructions. However, languages can also differ with regard to their overall level of
functionality. For example, a .NET language may or may not have a keyword to represent unsigned
data, and may or may not support pointer types. Given these possible variations, it would be ideal
to have a baseline to which all .NET-aware languages are expected to conform.
The CLS is a set of rules that describe in vivid detail the minimal and complete set of features a
given .NET-aware compiler must support to produce code that can be hosted by the CLR, while at
the same time be accessed in a uniform manner by all languages that target the .NET platform. In
many ways, the CLS can be viewed as a subset of the full functionality defined by the CTS.
The CLS is ultimately a set of rules that compiler builders must conform to, if they intend their
products to function seamlessly within the .NET universe. Each rule is assigned a simple name (e.g.,
“CLS Rule 6”) and describes how this rule affects those who build the compilers as well as those
who (in some way) interact with them. The crème de la crème of the CLS is the mighty Rule 1:
• Rule 1: CLS rules apply only to those parts of a type that are exposed outside the defining
assembly.
Given this rule, you can (correctly) infer that the remaining rules of the CLS do not apply to the
logic used to build the inner workings of a .NET type. The only aspects of a type that must conform
to the CLS are the member definitions themselves (i.e., naming conventions, parameters, and
return types). The implementation logic for a member may use any number of non-CLS techniques,
as the outside world won’t know the difference.
To illustrate, the following Add() method is not CLS-compliant, as the parameters and return
values make use of unsigned data (which is not a requirement of the CLS):
class Calc
{
// Exposed unsigned data is not CLS compliant!
public ulong Add(ulong x, ulong y)
{ return x + y;}
}
However, if you were to simply make use of unsigned data internally as follows:
class Calc
{
public int Add(int x, int y)
{
// As this ulong variable is only used internally,
// we are still CLS compliant.
ulong temp = 0;
...
return x + y;
}
}
you have still conformed to the rules of the CLS, and can rest assured that all .NET languages are
able to invoke the Add() method.
Of course, in addition to Rule 1, the CLS defines numerous other rules. For example, the
CLS describes how a given language must represent text strings, how enumerations should be
represented internally (the base type used for storage), how to define static members, and so forth.

Luckily, you don’t have to commit these rules to memory to be a proficient .NET developer. Again,
by and large, an intimate understanding of the CTS and CLS specifications is only of interest to
tool/compiler builders.