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).

The Common Type System (CTS) (which will be elaborated on later) and the CLS form a major part of the Common Language Infrastructure (CLI) specification. ^{[23] , [24]}

^[23] The CLI is ECMA-335 (blue cover). You can download it free of charge in pdf/postscript format at www.ecma.ch/ecma1/STAND/ecma-335.htm.

^[24] Microsoft has released a set of source codes for the CLI standards. Called the Shared Source CLI Implementation, it is freely downloadable and the licence permits you to modify and redistribute the source codes. The Shared Source CLI Implementation is not the 'real' source codes of commercial release standard, but it will interest inquisitive developers (who really have time on their hands), educational institutions, and software companies interested in porting .NET to another platform. Get it from http://msdn.microsoft.com/library/default.asp?url=/library/en-us/Dndotnet/html/mssharsourcecli.asp?frame=true

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:

• global static fields and methods of a class are prohibited ;

• only the following data types are CLS-compliant “ Byte , Int16 , Int32 , Int64 , Single , Double , Boolean , Char , Decimal , IntPtr and String ;

• methods are allowed to be overloaded based on the number and types of their parameters only;

• operator overloading is not CLS-complaint;

• pointer types and function pointer types are not CLS-compliant;

• for two identifiers to be distinct, they must differ by more than just their case.

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. ^[25] 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.

^[25] There is no such thing as an unsigned integer in Java (although if you have a background in C/C++ you would definitely have heard of the unsigned keyword). All Java numeric variables support signed storage, so that for a 32-bit signed integer (the Java int ) one bit is always reserved for the sign bit, leaving only 31 to store the actual value. There is no way to 'save' on that bit even if you are sure this int variable will never be used to store negative values. Unsigned integers are integers that have been declared so that they can be used only to store positive values. That leaves a 32-bit integer all 32 bits for storing the numeric value, thus effectively doubling the positive range of values it can store compared to a signed 32-bit integer. In C/C++, unsigned integers are declared using the unsigned keyword. In C#, there is no such keyword.

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. ^[26]

^[26] See http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconwritingcls-compliantcode.asp for some useful information on writing CLS-compliant codes.

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).

Figure 1.5. Both the CLS and CTS are part of the CLI specification.

Communication infrastructures which support interactivity between components on heterogeneous systems usually need a common set of types shared by all the different systems. ^[27] Similarly, in order for .NET to be cross-language, there is a set of common shared types used by all .NET languages.

^[27] A good example is CORBA. CORBA has a set of common IDL (language-neutral) types and a mapping table for each language that supports CORBA. This mapping table defines the language's type to its corresponding IDL type. (for example, Java's java.lang.String maps to IDL type string , and Java's byte maps to IDL type octet .) This enables different CORBA-enabled languages to pass objects of IDL types to one another without affecting the way the object is typed within the language itself.

The CTS defines how types are declared, used and managed during runtime. It performs the following roles:

• enables cross-language integration and type safety;

• defines rules that .NET languages must follow to ensure that objects written in different languages can interoperate.

Like Java, .NET languages are strongly typed. ^[28] 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.

^[28] In the quest for strong typing, VB .NET has got rid of the variant type of VB 6.

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. ^[29]

^[29] For Visual C++ programmers, you can roughly equate the BCL to MFC. But the BCL is much richer and much more powerful. There isn't much you can do with MFC besides the 'common stuff' such as drawing forms.

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 ^[30] ), .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. ^[31] The .NET BCLs in turn interact with the underlying Win32 APIs to perform their jobs.

^[30] In Java, the only way you can write code which utilizes OS-specific features is via JNI. JNI bridges native codes (perhaps written in natively-compiled C/C++) to platform independent Java codes. This is a significant trade-off to maintain Java's platform independence.

^[31] As such, it becomes impossible to port 100% of the .NET framework to other operating systems “ another reason why most would still classify .NET as a 'Windows-only thing'. Refer to section 1.10 for porting discussions.

The BCL includes APIs that cover almost every aspect of development: ^[32]

^[32] This book does not describe the BCL in detail, although Chapters 16 “ 19 introduce some useful classes.

• Windows GUI, controls, frames

• Networking

• Web browsing

• File system access

• Windows registry access

• Web forms (ASP .NET)

• COM interoperability

• Database access (ADO .NET).

A large portion of the BCL has been written in C# itself.

Instead of calling the Win32 API functions ^[33] 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.

^[33] Notice that I used the term 'functions' instead of 'methods'. The Win32 API has been written in non-object-oriented C. Most of the Win32 functions take in C pointers and references, and programming directly to the Win32 API can be difficult for programmers inexperienced (or careless) with pointers.

Figure 1.6. Invoking Windows functionality in different ways.