It is the life line of .NET applications. Before I describe the CLR - let's explain what is meant by runtime.
A runtime is an environment in which programs are executed. The CLR is therefore an environment in which we can run our .NET applications that have been compiled to IL.
Java programmers are familiar with the JRE (Java Runtime Environment). Consider the CLR as an equivalent to the JRE.
Important parts of CLR:
The Common Type System (CTS) is responsible for interpreting the data types into the common format - e.g. how many bytes is an integer.
The IL Compiler takes in the IL code and converts it to the host machine language.
The execution support is similar to the language runtime (e.g. in VB the runtime was VBRunxxx.dll; however with VB.NET we do not need individual language runtimes anymore).
Security component in the CLR ensures that the assembly (the program being executed) has permissions to execute certain functions.
The garbage collector is similar to the garbage collector found in Java. Its function is to reclaim the memory when the object is no longer in use; this avoids memory leaks and dangling pointers.
The class loader: Its sole purpose is to load the classes needed by the executing application
Here's the complete picture.
The programmer must first write the source code and then compile it. Windows programmers have always compiled their programs directly into machine code - but with .NET things have changed. The language compiler would compile the program into an intermediate language "MSIL" or simply "IL" (much like Java Byte code). The IL is fed to the CLR then CLR would use the IL compiler to convert the IL to the host machine code.
.NET introduces the concept of "managed code" and "unmanaged code". The CLR assumes the responsibility of allocating and de-allocating the memory. Any code that tries to bypass the CLR and attempts to handle these functions itself is considered "unsafe"; and the compiler would not compile the code. If the user insists on bypassing the CLR memory management functionality then he must specifically write such code in using the "unsafe" and "fixed" key words (see C# programmers guide for details). Such a code is called "unmanaged" code, as opposed to "managed code" that relies on CLR to do the memory allocation and de-allocation.
The IL code thus produced has two major issues with it. First it does not take advantage of platform specific aspects that could enhance the program execution. (for example if a platform has some complicated graphics rendering algorithm implemented in hardware then a game would run much faster if it exploit this feature; however, since IL cannot be platform specific it can not take advantage of such opportunities). Second issue is that IL can not be run directly on a machine since it is an intermediate code and not machine code. To address these issues the CLR uses an IL compiler. The CLR uses JIT compilers to compile the IL code into native code. In Java the byte code is interpreted by a Virtual Machine (JVM). This interpretation caused Java applications to run extremely slow. The introduction of JIT in JVM improved the execution speed. In the CLR Microsoft has eliminated the virtual machine step. The IL code is compiled to native machine and is not interpreted at all. For such a compilation the CLR uses the following two JIT compilers:
Econo-JIT: This compiler has a very fast compilation time; but it produces un-optimized code - thus the program may start quickly but would run slow. This compiler is suitable for running scripts.
Standard-JIT: This compiler has a slow compilation time; but it produces highly optimized code. Most of the times the CLR would use this compiler to run your IL code.
Install Time Compilation: This technique allows CLR to compile your application into native code at the time of installation. So the installation may take a few minutes more - but the code would run at speeds close to a native C/C++ application.
Once your program has been compiled into host machine code, it can begin execution. During execution the CLR provides security and memory management services to your code (unless you have specifically used unmanaged code).
