This is a continuation of a previous post about .NET framework and these series are aim at presenting information about .NET framework that will hopefully make sense from a non-technical perspective. .NET is an interesting platform but its design and implementation has remain a mystery largely though there is sufficient information to describe it as well as its various implementation. Microsoft released the fundamental blue prints of the framework to the ECMA (European Computer Manufacturers Association) for the standardization hence it is accurate to conclude that Microsoft.NET (the framework) is an implementation of this standard though it is also prudent to keep in mind how much Microsoft’s implementation conforms to the publicly available standard.
The Common Language Infrastructure is the standard that has been endorsed by ECMA as ECMA 335. There are other standards related to the .NET Framework such as those that underpin the C# programming language. To paraphrase the standard documents, the CLI provides an environment in which applications written in multiple high level programming languages may execute in different environments without modification to adopt the application to the unique features of the target environment. Sounds like a complicated way of saying that it is just a virtual machine that abstract the application away from the details of the environment that host the virtual machine. While that’s the simple way of explaining what the CLI is, it is by no means the most comprehensive way of gaining a better understanding of it.
Whenever there is a discussion of the .NET framework there would almost certainly be reference to Java and perhaps it would be foolish to assume that Java has not had an influence on how, at least some, aspects of .NET were designed and implemented. However, the .NET framework is unique in its design to support multiple programming languages (which the JVM is capable of as well) but that’s a rather simplistic view of the support of multiple programming languages on .NET. The .NET framework goes an extra mile in making language integration and harmony amongst the various programming languages that target the CLR. Understanding the difference between support for multiple programming languages and language integration cannot be overemphasized: the GCC (GNU Compiler Collection) support multiple programming languages but the support languages are not integrated which means that code written in one language cannot be easily used in the other languages without modification. The support for language integration on the .NET framework means that exceptions thrown from VB.NET code can be caught and processed by C# or any other supported language and vice versa.
As mentioned above, the GCC set supports multiple programming languages and though that in itself is an interest subject to examine, it will have to be done in another day. Ask yourself this: what would it take to support language integration in a manner which the binaries written in one language would understand the stuff that come out of binaries written in other support language? If you are getting to the conclusion that the answer is like to be complex then you perhaps headed in the right direction in getting an epiphany of what the CLI is made up of.
The CLI is essentially an umbrella terminology used to refer to components that act together in tandem to realize multiple programming languages support as well as harmony between these languages. Its architecture comprises of the following key components:
- Common Type System: Based on the example of exceptions being thrown and caught across language boundaries, each language that targets the CLR needs to have an understanding of an exception and the Common Type System (CTS) helps in establishing a common understanding of types across programming languages. However the CTS is not only limited to exception types – from the specification – the CTS is a unified type system that is shared by compilers, tools, and the CLI itself. It is the model that defines the rules the CLI follows when declaring, using, and managing types. The CTS establishes a framework that enables cross-language integration, type safety, and high performance code execution.
- Virtual Execution System: if you have already concluded that this is what is called the CLR in the .NET framework then you wouldn’t be any where but on the truth of the matter. Various analogies come to mind to help describe the VES but for all intends and purposes it is the equivalent of the brains of the CLI as it is charged with implementing and enforcing the CTS. The VES is responsible for loading and running programs that are written for the CLI.
- Common Language Specification: this aspect of the CLI architecture is described as an agreement between language designers and class library designers. The CLS specifies a sub set of the CTS and a set of rules that govern usage patterns. When language designers implement the CLS, they ensure that their users have access to frameworks that support the CLS. Similarly framework designers implement the CLS on the publicly accessible aspects of their class libraries and thus allow their frameworks to be accessed from CLS compliant languages.
- Metadata: the operations of the CLI are metadata driven which means that every aspect of the system is described in metadata hence allowing communication across the various components that make up the CLI. Metadata is what describes the meaning of various entities of an implementation of the CLI.
This post dwelled on the architecture of the CLI which is defined by Partition I of the ECMA 335 standard which is currently at 4th edition (release in June 2006) as of this writing. The standard document defines six partitions.