|[ directory ]|
1.7 Common language infrastructure
You have seen that .NET supports multiple languages because the source codes of these languages are eventually compiled into IL codes. This has a serious implication ?there must be a common minimum standard which all these .NET languages need to follow. There are certain rules that all must adhere to (or else they will never be able to be converted into the universal IL code). This set of rules is the Common Language Specification (CLS).
1.7.1 The Common Language Specification
It is important that .NET objects ?regardless of whether they are written in .NET COBOL or C# ?should only expose (i.e. make protected or public) features that are common to all other .NET languages which they interoperate with. The CLS is the set of common language features that must be adhered to if you want to develop a new programming language targeted at .NET.
It is possible for a language to extend the feature set specified in the CLS with additional language features. But exposure of these extended features for interfacing with external classes may spell trouble for interoperation. If you want to write components that can interoperate seamlessly with other .NET components (which may be written in any other .NET language), ensure that you use only CLS-compliant features of your language.
Examples of some clauses in the CLS are:
A good example to illustrate non CLS-compliance is the case sensitivity of identifiers. Some CLS-compliant .NET languages can be case sensitive (such as C#, or J#) while others do not differentiate between an upper case 'A' and a lower case 'a' (such as VB .NET). For the latter group of languages, the variable name apple is not distinguishable from APPLE, nor aPPlE. Using a case sensitive language such as C#, you can easily declare two distinct variables APPLE and apple within the same scope and make the program work. This is because C# has a feature set bigger than that specified in the CLS ?in particular, the feature of case sensitivity.
Nevertheless, a class written in this manner may not interoperate with another class written in VB .NET for, as far as VB is concerned, the variables APPLE and apple within the same scope are identical.
Here is another example. Most (not all) of the types in the .NET BCL are CLS-compliant. An example of a non-CLS compliant type is the unsigned integer.  C# supports unsigned integers via the uint keyword. However, the CLS does not support unsigned types. Again, if you want to ensure that your C# codes are CLS-compliant, your public methods should not return unsigned variables even though the language provides such a feature. It is all right if you use uint local variables or private class members because they will not be visible outside the method or class. However, public or protected members in a non-private class are 'exposed' and hence should follow CLS rules if you want your codes to be CLS-compliant.
To ensure that your classes do work with other classes written in other .NET languages, it may be worth spending some time taking a look at the CLS. 
According to Microsoft, "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."
1.7.2 The common type specification
I mentioned earlier that the CLI also includes the CTS (see Figure 1.5).
Communication infrastructures which support interactivity between components on heterogeneous systems usually need a common set of types shared by all the different systems.  Similarly, in order for .NET to be cross-language, there is a set of common shared types used by all .NET languages.
The CTS defines how types are declared, used and managed during runtime. It performs the following roles:
Like Java, .NET languages are strongly typed.  According to the CTS, all types can be broadly categorized into two groups ?value types and reference types. Like value types in Java, value types in .NET are types that store a value. Similarly, reference types are types that store the memory address of an object. It is possible to have two reference types referring to the same object stored at a shared memory location.
Adherence to both the CTS and CLS ensures that codes written in any .NET language interoperates with codes written in any other .NET language.
1.7.3 The base class libraries
What you can do with a language will be severely limited if it doesn't come with a rich set of ready-made classes that you can just use. Like Java's core API classes, .NET comes with a set of .NET BCLs. 
However, unlike Java's core classes, which avoid any platform-specific features (and hence provides platform independence at the expense of not being able to utilize platform-specific features ), .NET's BCL contains powerful classes for your codes to interact with Windows-specific features. For example, a .NET program can use classes in the .NET BCL to read from or write to the Windows registry.  The .NET BCLs in turn interact with the underlying Win32 APIs to perform their jobs.
The BCL includes APIs that cover almost every aspect of development: 
A large portion of the BCL has been written in C# itself.
Instead of calling the Win32 API functions  directly, .NET applications use methods of classes in the BCL, (see Figure 1.6). While traditional windows programs access the operating system directly by calling the Win32 API. Visual C++ developers have the luxury of using a set of API classes called MFC which made programming Windows applications so much easier. The MFC abstracts low level details such as the creation of a Windows frame or button. Unfortunately, one common grouse of C++ programmers is that the MFC is not comprehensive enough ?programmers still have to make direct calls to the Win32 API for less commonly used functionalities absent in the MFC. .NET applications access the operating system's functions via the BCL and never directly, because they execute within the .NET CLR.
|[ directory ]|