The common language runtime, similar to the Java runtime, is the substrate of the .NET Framework. The common language runtime resides just above the operating system and provides functionality such as memory management and garbage collection to the .NET Framework. The common language runtime implements and uses a type system that is baked into every aspect of the Framework. These types are accessible by all programming languages, thus facilitating cross-language interoperability.
The common language runtime is a complete execution engine. Programming languages that target the .NET Framework translate source code into special instructions that the common language runtime can understand (more about this shortly). Code that targets the common language runtime is known as managed code. Managed code takes advantage of cross-language integration, cross-language exception handling, enhanced security, versioning and deployment support, a simplified model for component interaction, and debugging and profiling services.
.NET language compilers output Microsoft intermediate language (MSIL). MSIL is data that contains information that provide descriptions about code. This self-describing data contains information about the data types used; the classes, methods, and properties used; security and context; and any other information the common language runtime requires to execute an application. A methodology known as reflection exists whereby a .NET assembly can be interrogated for such information.
An important element that the common language runtime offers is automatic memory management. With automatic memory management, managed applications never need to worry about releasing memory after it has been allocated and used, because their memory is automatically reclaimed when it is no longer needed. This means there are no more memory leaks (memory that never gets freed). Because C++ applications have been notorious for their memory leaks, this one common language runtime feature alone will lure many C++ programmers to the .NET world.
The common language runtime's memory management system is advanced. It not only eliminates memory leaks; it also provides high-performance memory allocation, which can make applications perform much faster overall. This improved performance means that the cost of allocating memory is reduced compared to traditional memory allocation strategies.
Compilers that target the .NET Framework expose the runtime's functionality in ways intended to be useful and intuitive to their developers. This means that some runtime features might be more noticeable in one environment than in another. For example, how you as a developer experience runtime depends on which language compilers or tools you use. If you are a Visual Basic developer, you might notice that, with the common language runtime, the Visual Basic language has more object-oriented features than before. The following benefits of the runtime might be particularly interesting to you:
When a .NET language is compiled, it isn't output as native x86 code (the binary machine codes that 80x86 family CPUs execute). The binary image that's saved contains a small amount of bootstrap x86 code (which kicks off the common language runtime's execution engine MSCOREE.DLL), the metadata (the self-describing data), and the MSIL body of data.
MSIL cannot be executed by x86 CPUs. MSIL is intermediate language, similar to what is known as pseudo code. MSIL is somewhere between the language source code and the machine code. It has been compiled into a form in which it can be turned into machine code many compiler operations have already been performed, and the step from MSIL into machine code is relatively easy.
At execution time, the common language runtime takes the MSIL and compiles it into machine code that can be executed by the CPU. This process is known as just-in-time (JIT) compilation. The common language runtime doesn't, however, compile the entire application image, but compiles each discreet piece of code as it is needed. The compiled machine code stays in memory in its compiled form until the application is terminated.
You might be asking why the compilers output MSIL instead of machine code. At first glance, to simply output machine code would seem more practical after all, that's what the CPU needs to correctly execute the intentions of the programmer. Microsoft, however, has made MSIL an open specification, in the hope and with the plan that non-Microsoft platforms such as UNIX will eventually implement a common language runtime and thus be able to use the same MSIL that a Windows-based operating system uses.