Nbsp;   The Common Language Specification

COM allows objects created in different languages to communicate with one another. On the other hand, the CLR now integrates all languages and allows objects created in one language to be treated as equal citizens by code written in a completely different language. This integration is possible be- cause of the CLR’s standard set of types, metadata (self-describing type information), and common execution environment.

Although this language integration is a fantastic goal, the truth of the matter is that programming languages are very different from one another. For example, some languages don’t treat symbols with case-sensitivity, and some don’t offer unsigned integers, operator overloading, or methods to support a variable number of arguments.

If you intend to create types that are easily accessible from other programming languages, you need to use only features of your programming language that are guaranteed to be available in all other languages. To help you with this, Microsoft has defined a Common Language Specification (CLS) that details for compiler vendors the minimum set of features their compilers must support if these compilers are to generate types compatible with other components written by other CLS-com- pliant languages on top of the CLR.

The CLR/CTS supports a lot more features than the subset defined by the CLS, so if you don’t

care about interlanguage operability, you can develop very rich types limited only by the language’s feature set. Specifically, the CLS defines rules that externally visible types and methods must adhere to if they are to be accessible from any CLS-compliant programming language. Note that the CLS rules don’t apply to code that is accessible only within the defining assembly. Figure 1-6 summarizes the ideas expressed in this paragraph.

As Figure 1-6 shows, the CLR/CTS offers a set of features. Some languages expose a large subset of the CLR/CTS. A programmer willing to write in IL assembly language, for example, is able to use all of the features the CLR/CTS offers. Most other languages, such as C#, Visual Basic, and Fortran, expose a subset of the CLR/CTS features to the programmer. The CLS defines the minimum set of features that all languages must support.

FIGURE 1-6Languages offer a subset of the CLR/CTS and a superset of the CLS (but not necessarily the same superset).

If you’re designing a type in one language, and you expect that type to be used by another lan- guage, you shouldn’t take advantage of any features that are outside of the CLS in its public and protected members. Doing so would mean that your type’s members might not be accessible by programmers writing code in other programming languages.

In the following code, a CLS-compliant type is being defined in C#. However, the type has a few

non–CLS-compliant constructs causing the C# compiler to complain about the code.

using System;

// Tell compiler to check for CLS compliance [assembly: CLSCompliant(true)]

namespace SomeLibrary {

// Warnings appear because the class is public public sealed class SomeLibraryType {

// Warning: Return type of 'SomeLibrary.SomeLibraryType.Abc()'

// is not CLS­compliant

public UInt32 Abc() { return 0; }

// Warning: Identifier 'SomeLibrary.SomeLibraryType.abc()'

// differing only in case is not CLS­compliant public void abc() { }

// No warning: this method is private private UInt32 ABC() { return 0; }

}

}

In this code, the [assembly:CLSCompliant(true)] attribute is applied to the assembly. This attribute tells the compiler to ensure that any publicly exposed type doesn’t have any construct that would prevent the type from being accessed from any other programming language. When this code is compiled, the C# compiler emits two warnings. The first warning is reported because the method Abc returns an unsigned integer; some other programming languages can’t manipulate unsigned integer values. The second warning is because this type exposes two public methods that differ only by case and return type: Abc and abc. Visual Basic and some other languages can’t call both of these methods.

Interestingly, if you were to delete public from in front of 'sealed class SomeLibraryType' and recompile, both warnings would go away. The reason is that the SomeLibraryType type would default to internal and would therefore no longer be exposed outside of the assembly. For a com- plete list of CLS rules, refer to the “Cross-Language Interoperability” section in the .NET Framework SDK documentation (http://msdn.microsoft.com/en-us/library/730f1wy3.aspx).

Let me distill the CLS rules to something very simple. In the CLR, every member of a type is either a field (data) or a method (behavior). This means that every programming language must be able to access fields and call methods. Certain fields and certain methods are used in special and common ways. To ease programming, languages typically offer additional abstractions to make coding these common programming patterns easier. For example, languages expose concepts such as enums, arrays, properties, indexers, delegates, events, constructors, finalizers, operator overloads, conver- sion operators, and so on. When a compiler comes across any of these things in your source code, it must translate these constructs into fields and methods so that the CLR and any other programming language can access the construct.

Consider the following type definition, which contains a constructor, a finalizer, some overloaded operators, a property, an indexer, and an event. Note that the code shown is there just to make the code compile; it doesn’t show the correct way to implement a type.

using System;

internal sealed class Test {

// Constructor public Test() {}

// Finalizer

~Test() {}

// Operator overload

public static Boolean operator == (Test t1, Test t2) { return true;

}

public static Boolean operator != (Test t1, Test t2) { return false;

}

// An operator overload

public static Test operator + (Test t1, Test t2) { return null; }

// A property

public String AProperty { get { return null; } set { }

}

// An indexer

public String this[Int32 x] { get { return null; }

set { }

}

// An event

public event EventHandler AnEvent;

}

When the compiler compiles this code, the result is a type that has a number of fields and methods defined in it. You can easily see this by using the IL Disassembler tool (ILDasm.exe) provided with the

.NET Framework SDK to examine the resulting managed module, which is shown in Figure 1-7.

FIGURE 1-7ILDasm showing Test type’s fields and methods (obtained from metadata).

Table 1-4 shows how the programming language constructs got mapped to the equivalent CLR

fields and methods.

TABLE 1-4Test Type’s Fields and Methods (Obtained from Metadata)

The additional nodes under the Test type that aren’t mentioned in Table 1-4—.class, .custom, AnEvent, AProperty, and Item—identify additional metadata about the type. These nodes don’t map to fields or methods; they just offer some additional information about the type that the CLR, programming languages, or tools can get access to. For example, a tool can see that the Test type offers an event, called AnEvent, which is exposed via the two methods (add_AnEvent and remove_ AnEvent).

Date: 2016-03-03; view: 684