CHAPTER 1 THE PHILOSOPHY OF .NET
Given the fact that the unique keywords of a managed language are simply shorthand notations for
a real type in the System namespace, we no longer have to worry about overflow/underflow conditions
for numerical data, or how strings and Booleans are internally represented across different languages.
Consider the following code snippets, which define 32-bit numerical variables in C# and Visual Basic,
using language keywords as well as the formal CTS data type:
// Define some "ints" in C#.
int i = 0;
System.Int32 j = 0;
' Define some "ints" in VB.
Dim i As Integer = 0
Dim j As System.Int32 = 0
Understanding the Common Language Specification
As you are aware, different languages express the same programming constructs in unique, languagespecific terms. For example, in C# you denote string concatenation using the plus operator (+), while in
VB 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 might or might not have a keyword to represent unsigned data, and might or
might 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 Rule 1.
Rule 1: CLS rules apply only to those parts of a type that are exposed outside the
defining assembly.
19