Common Language Infrastructure

The Common Language Infrastructure (CLI) is the foundation, or rather a subset, on which .NET Framework is built on. It is the part that Microsoft chose to standardize (ISO/IEC 23271 and ECMA-335) upon the the first release of the Framework and it involves many of the core aspects of the runtime engine and its base class library. Today there are a couple of other implementations of the standard. Mono is the most popular of them and brings most of the functionality of the .NET Framework to Linux and Mac OS X. Another is the DotGNU project.

CLI provides guidelines for developing platforms on which programming language can be built and easily communicate with each other.

The CLI standard defines the following parts:

• Common Type System (CTS)
  Defines a common set of rules for data types that are shared by all CTS-languages 
• Metadata
  Information about the structure of the programs. The information is language-agnostic and makes it easier to share information between different programming languages.
• Common Language Specification (CLS)
  The rules that any CLI-compatible language must conform to be able to fully operate with other languages on the platform.
• Virtual Execution System (VES)
  Defines the common execution engine that executes the programs built for the CLI. It combines separately generated pieces of code at runtime by using the metadata.

In one sentence: The standard simply defines a virtual execution system, or virtual machine, and the basic components around it, as the base class library.

The goal of is to make it easier for programmer to write platform agnostic programs that can be executed in a safe mode in a virtual execution environment. Another goal is to make it easier for programming languages to interoperate by sharing one common underlying platform with common rules which they all conform to.

Types and Memory management

The Common Type System (CTS) defines value types and reference types. Typical value types are the primitive types, like int and char. These are native to the runtime (the VES) and are stored in a memory location called the stack. String is not a primitive type nor a value type, but a reference type, an instance (object) of a class. A reference type is stored on the heap. These two are named after the way they are handled.

Values are actual values and objects are instances of classes that can be accessed through a reference. Both are bound to a scope and there are no globals.

The stack and the heap are handled by the runtime. The memory occupied by values and objects are allocated and freed by it. In traditional unmanaged languages like C/C++ the programmer needs to handle the memory management by himself. That is a painful process that takes a lot of time. It is most importantly dangerous to handle memory the wrong way. A simple error may cause the computer to crash or worse. Now with memory management, the programmer can focus on productivity instead.

In the .NET Framework there is a garbage collector which discards the references and frees the memory to the heap when it is no longer reachable in code.

There is also functionality as well as a framework for handling exceptions. The runtime shall abort when an exception is thrown and the programmer shall handle it.

Object Oriented Programming

The CLI is developed for native support of Object Oriented Programming (OOP). Every instance of a type can be regarded as an object. There is no difference in the way value types and reference types are accessed, except the way the runtime treats them.

You can use OOP all down to the CIL. There are instructions in the instruction set that can create instances and access the members.

Value types such as the primitive types have wrapper classes that extends from the System.ValueType class.

A static runtime

The Common Language Infrastructure defines a type system that is statically typed and a set of instructions that handles them. The reason was that Microsoft firstly wanted to embrace type safety with static typing, and of course, the statically typed languages was the most popular ones when the .NET project was started. Whereas, it is possible to run dynamically typed languages directly on top of the platform.

However, Microsoft has created the Dynamic Language Runtime (DLR) to make it easier for dynamically typed languages to run on top of it. The DLR is a static library that translates dynamic calls into static actions at runtime using Reflection and expression trees. The DLR can be freely downloaded and redistributed.

Metadata and Reflection

Metadata makes the CIL powerful. It is information about the structure of the program and it is very important during the execution process. The metadata can be edited and even generated at runtime through reflection. You are able to generate a class, method or even IL at runtime.

Common Intermediate Language

An executable program file is called an assembly. It contains the metadata and code written in the so called Common Intermediate Language (CIL). The CIL, or simply IL, has an instruction set with instructions much like the ones of a CPU. There is also an assembly language which is the form of code that is closest to the IL but still readable  for humans. 

This is the classic Hello World-program handwritten in CIL:

.assembly extern mscorlib {}
.assembly hello {}
.method static public void main() cil managed
{
  .entrypoint
  .maxstack 1
  ldstr "Hello, World!"
  call void [mscorlib]System.Console::WriteLine(class System.String)
  ret
}

Article about this code: http://en.csharp-online.net/HelloWorld_in_MSIL

Note: It can be assembled with the ILASM utility in .NET Framework and Mono Framework. Likewise you can disassemble an assembly into IL assembler code using ILDASM, or similar.

If you are interested in learning some more about IL you should check this article at CodeProject.

Base Class Library

There is also a rich Base Class Library (BCL) to be implemented. It shall contain the basic functionality that is needed when developing an application for the a CLI-based platform.

Furthermore, the base class library is updated in every build of the .NET Framework.

Note that not all of the BCL-classes in the official .NET implementation are standardized. The APIs of the standardized BCL are listed here.

Compile once. Run everywhere.

The programs written for the CLI are platform agnostic and can be compiled once and later executed on every platform that implements the specification. But Microsoft does only provide one working implementation (.NET Framework) for Windows, and that is a superset of the standard. So if you do not have the specified libraries you will not be able to run your program. Mono gives support for Linux and Mac OS X through their open source implementation of the CLI, including the extensions of the .NET Framework.

This is similar to Java which also has an implementation for every platforms which enables the programs targeting their platform to run. It is not standardized though.

License

Added: July 10, 2009

Microsoft is going to apply the Community Promise license to the ECMA 334 and ECMA 335 specs (CLI and C#). This will make it possible for anyone to implement specifications and do what they want with the product without the permission from Microsoft.

The license is irrevocable once it is applied. This is good for the open source community.

Read more: http://port25.technet.com/archive/2009/07/06/the-ecma-c-and-cli-standards.aspx

Source of information:  From Microsoft: C# and CLI under the Community Promise at Miguel de Icaza’s WebLog.

Implementations

Here is a list of the most common implementations of the CLI.

• .NET Framework is Microsoft’s commercial implementation which is built on their execution engine, Common Language Runtime (CLR). Available for Windows, and was formerly (v. 2.0) for Mac OS X too. The CoreCLR is used by Silverlight on Windows and Mac OS X.
• Shared Source Common Language Infrastructure (SSCLI), formerly known as ROTOR, is a reference implementation of the CLR. Distributed under  Microsoft Shared Source License.
• .NET Compact Framework is Microsoft’s implementation for portable devices and Xbox 360.
• Mono Framework is an open source implementation of the CLI for Linux, Mac OS X and Windows. The project aims to be almost 100% compatible with .NET Framework.
• Portable.NET is part of the dotGNU project, open source/free software by Free Software Foundation.

External links

Some valuable resources.

• ECMA C# and Common Language Infrastructure Standards at MSDN
• Microsoft .NET
• Mono Project

First days in Delsbo

3 days ago my family and I went on our yearly holiday trip to the place where my father is from. Every year we go to this place in Hälsingland called Delsbo, where my grandmother and most of my other relatives on my fathers side live. It was a great feeling being back again. These 12 hours I spent in the car really had paid off. Every time I come back It feels like I’m home. I see mountains. I see a lot of forests and lakes. Something rare back in Scania with its big plains.

Dellenbygden

The weather has been great so far, a bit too great. It has taken some time to adapt to the warmth. But today It has been quite a enjoyable day. Neither cold or hot. I went swimming in Sördellen, one of the great Dellen lakes. The temperature in the water was about 22 deg. Celsius. I later spent the evening with some relatives.

Tomorrow (Sunday, July 5) it is spelmansstämma at Delsbo forngård, an ancient farm. A lot of folk musicians are coming to play traditional folk music. People come and meet new people and also experience a bit of the culture of this area.  One of the things that a visitor should not miss is ostkaka (lit. cheesecake). It is indescribable for those who haven’t tasted it. And if you are from Delsbo or any other place you may wear your own traditional regional costume. Delsbo has its own and almost everyone here has got one which they wear at special occasions. The spelmanstämma  has been held for more than a 100 years now, and it is well known around the country.

The spelmansstämma (musician gathering) is held every year in the first weekend of June. This is strictly a folk music festival. There are a couple of other events like this but not all of them is are devoted to just folk music. One of them is in Bjuråker two weeks from the one in Delsbo. It is a larger event than Delsbo, which is the oldest. Many prefer to visit it instead.

Delsbo is an average town located at the southwest shore of Sördellen, the southern lake. It is about 30 kilometers from Hudiksvall, the nearest big town. There’s a school (elementary and upper) and there’s two supermarkets. Normally it does not seem to be much life in this town but in the summer it becomes flourishing because of the summer residents.

Delsbo

I would like to tell more about the Dellen lakes. That is a landmark which also has given the town its name. The lakes form a lake system in two craters originally created when meteorites fell down on Earth millions of years ago. Due to volcanic activity in the ground a special type of rock was created from the lava which came from the ground. It is called Dellenite. There are two types of it: the red one from the southern lake and the black one from the northern. The Dellenite has become the regional rock type of the whole province of Hälsingland.

I really like being back in Delsbo and I think this summer will be at least as good as the ones I have spent here before.

Dynamic typing in C#

As I wrote in the previous blog post about the Dynamic Language Runtime (DLR) some of the statically typed general purpose programming languages already available on the .NET platform will contain constructs which makes it easier for them to interoperate with the DLR and the languages upon it. In this article I will introduce you to the new features in C# 4.0, and the new dynamic type which brings dynamic typing to the language. I will try to explain what really happens under the hood.

The code I will be showing must be compiled using the .NET Framework 4.0 Beta 1. It can be downloaded here. Visual Studio 2010 Beta 1 can be downloaded at the same location.

Dynamic type

In C# 4.0 you are introduced to the new dynamic type. Some may wonder why somebody would like to add something that would break the type-safety of the language. But if you learn more you realize that a variable of type dynamic is statically typed to be dynamic at runtime. It will forever (in terms of scope) be dynamic and be able to hold any type of object.

dynamic x = "Hello, World!";
x = 2;  //Valid because it is of type "dynamic".

The current type of the object held by the dynamic variable is unknown at compile-time and will always be resolved at runtime, hence if you make a call to a method the compiler would not complain if it turned out to not be a valid action.

dynamic foo = "foobar";
stringstr = foo.ToUpper();

foo.Bar(); //Not a member of String. Runtime exception.

As seen in the next example the dynamic type will automatically try to cast its object if you try to assign it to a variable typed other than dynamic.

dynamic foo = "foobar";
string a = foo;  //Will pass this.
int b = foo;  //Will fail at runtime.

As seen in these examples dynamic is a type that is handled at runtime.

There are no checks at compile-time which makes it an “unsafe” type to use when it comes to handling types.

It is best not to use it for other than interop with dynamic programming languages like IronPython. So it is not a type you would normally use in C#.

It is preferred that you stay with your old habit of static typing.

Note: Visual Studio will not provide any IntelliSense for dynamic variables because the type is uncertain before runtime. The same with member calls.

VS cannot be sure of the type before it is executed. If you are using Javascript in you will not find this so surprising.

Behind the scenes

Now to the most interesting part. What does the IL that is generated by the compiler look like? Lets dive into it.

We have this program:

dynamic A = 42;
Console.WriteLine(A);

This program actually does nothing that is useful. It only assigns the value 42 to

the variable A of type dynamic and then prints it out with a call to Console.WriteLine.

This is the disassembly in .NET Reflector:

object A = 42;
if (<Main>o__SiteContainer0.<>p__Site1 == null)
{
    <Main>o__SiteContainer0.<>p__Site1 = CallSite<Action<CallSite, Type, object>>.Create(new CSharpInvokeMemberBinder(CSharpCallFlags.None, "WriteLine", typeof(Program), null, new CSharpArgumentInfo[] { new CSharpArgumentInfo(CSharpArgumentInfoFlags.IsStaticType | CSharpArgumentInfoFlags.UseCompileTimeType, null), new CSharpArgumentInfo(CSharpArgumentInfoFlags.None, null) }));
}
<Main>o__SiteContainer0.<>p__Site1.Target(<Main>o__SiteContainer0.<>p__Site1, typeof(Console), A);

As seen you actually assign 42 to a variable of type object. The variable will therefore be able to contain a reference to any kind of object, because every object inherits from the .NET base class Object.

What is not quite obvious is the calls done under that first line of code.

This code interacts with the DLR and makes it possible to resolve and do safe calls at runtime instead of compile-time, which is the usual way in C#.

The DLR is using CallSites to be able to resolve members at runtime.

CallSites

A CallSite is a type that performs lookups on members called dynamically at runtime. It can be a call to a member of a dynamic variable. In that case it is impossible to know at compile-time if it really exists. CallSites automatically checks if the action is valid.

In our disassembled code it first checks if the CallSite has been initialized, else it initializes it with a CallSite that functions as an member invoker.

It is set to work with the method we want to call, Console.WriteLine. Our argument is dynamic and we have to see if its value can be passed to any of its overloads. This is performed at the last line where the argument is passed into the DLR. If this is invalid the DLR would throw a runtime exception.

This is kind of silly here because Console.WriteLine takes object as an argument in one overload so this does not make any good use in this example.

In the assembly generated by the C# compiler you will find that CallSites live in a nested static class named something like <Main>o__SiteContainer0.

CallSites are simply static fields of the generic CallSite<T> class.

[CompilerGenerated]
private static class <Main>o__SiteContainer0
{
    // Fields
    public static CallSite<Action<CallSite, Type, object>> <>p__Site1;
}

Now where going to view one last sample. This time we call an object member.

We compile the code and then disassemble it for study.

dynamic A = "Test";
string r = A.ToUpper();

This is what .NET Reflector gives you:

object A = "Test";
if (<Main>o__SiteContainer0.<>p__Site1 == null)
{
    <Main>o__SiteContainer0.<>p__Site1 = CallSite<Func<CallSite, object, string>>.Create(new CSharpConvertBinder(typeof(string), CSharpConversionKind.ImplicitConversion, false));
}
if (<Main>o__SiteContainer0.<>p__Site2 == null)
{
    <Main>o__SiteContainer0.<>p__Site2 = CallSite<Func<CallSite, object, object>>.Create(new CSharpInvokeMemberBinder(CSharpCallFlags.None, "ToUpper", typeof(Program), null, new CSharpArgumentInfo[] { new CSharpArgumentInfo(CSharpArgumentInfoFlags.None, null) }));
}
string r = <Main>o__SiteContainer0.<>p__Site1.Target(<Main>o__SiteContainer0.<>p__Site1, <Main>o__SiteContainer0.<>p__Site2.Target(<Main>o__SiteContainer0.<>p__Site2, A));

There are two CallSites in this code. The first one is a converter and the second is a member invoker. The action is performed on the last line of code. It involves the lookup and the call to the the member ToUpper. The result is converted to a string and stored in the string variable r.

If you want to check out these features you got to download Visual Studio 2010 Beta 1.