Over the weekend, I found myself engrossed in a book about Microsoft’s .NET Framework and though the book was old (relative to the current state of affairs as pertains to Microsoft .NET). The book was based on Microsoft.NET framework version 1.1 which was released back in 2003 which in any normal measure of time was not long ago but in Internet measure of time, that likes ages ago. Anyhow, we are currently in version 3.0, with version 3.5 currently in beta as of this writing. The introduction of .NET was perhaps a confusing moment which was not helped by the fact that every other Microsoft division or product group was contemplating products with a .NET suffix at the end of it which inevitably meant that the true meaning of Microsoft.NET was not immediately apparent to the rest of the world which wanted to come to grips with this new creation of Microsoft.
The book titled .NET Framework Essentials give an overview of the design goals of Microsoft.NET and indeed the understanding of the what the framework was at the time version 1.1 was released. Much of it remained true, I suppose since the the framework is increasing integrated into a lot more Microsoft products but it has largely been de-emphasized in products whose audience wouldn’t care any more about language independence and integration.
Anybody who has an idea of what the .NET framework is knows about the CLR and the central role it plays in making the promise of .NET a reality; reading the book also gave me a better understanding of how the CLR works and indeed how language integration is achieved on the framework. The .NET framework makes pervasive use of meta data which describes the types, resources, security, threading details of the code that will be executed by the CLR. The metadata is stored in a manner that is language agnostic which means that any language and tool that targets the CLR can make use of descriptive and referencing information that is the metadata. This data about data is also used by tools to enable compatibility with already deployed technologies like COM: you have type library exporters that make COM components appear like a .NET assembly (the basic unit of deployment in the .NET universe) which means that existing COM components can interoperate with new code that typically targets the CLR. The exporter is just one of many tools that makes the framework interoperate with existing technologies.
The .NET framework is immensely huge and in the spirit of most of the computer related technologies that have come, there are a slew of acronyms that describes aspects of it. In the .NET work these include include acronyms like CLR (Common Language Runtime) which largely makes sense and can be adequately described as a virtual machine environment that compiles IL (Intermediate Language) code and manages the execution of the resultant native code. One of the key differences between the CLR and JVM (Java Virtual Machine), besides the fact that former works with IL and the latter works on bytecode, is that the CLR never interprets IL; the IL code is JIT compiled into native code and executed as such. The JIT compilation is made more efficient by the extensive support of metadata in the .NET framework which basically means that the JIT compiler can compile a small section of a .NET assembly (deployment unit) and thus not require a slow down in program execution – compilation is done incrementally without much negative effect to program execution. With the extensive support for Metadata, the management of execution (which includes type checking, exception handling, debugging, security and of course the all important garbage collection) can proceed without requiring the entire compiled .NET assembly to be loaded.
Key to the functioning of the CLR are other technologies/specifications that goes by acronyms such as CTS, CLS, CLI which stand for Common Type System, Common Language Specification and Common Language Infrastructure. A little digging into this most impressive alphabet soup revealed that all these acronyms are under the general umbrella of the CLI according to the ECMA documentation that defines a CLR like standard; in fact the CLR is Microsoft’s implementation of the CLI.