CLR Execution Process

1. Choosing the Source Code language compiler.
   At this stage we can choose the source code language for .NET. The primary languages available are C#, VB.NET and Python.
   
2. Compiling the source code to MSIL assemblies using the language compiler.
   Compiling the source code using the language compiler generates the corresponding assembly containing the MSIL. The assembly can be either a .exe or a .dll depending on the entry point defined in the Application.
   
3. Executing the code by CLR
   The operating system loader checks the COFF header for a managed module. When a bit in the COFF header is set on then that denotes a managed module. If the loader detects a managed module it loads mscoree.dll which denotes the runtime execution engine; mscoree.dll loads and executes the .Net assemblies.

At execution time the CLR converts the MSIL to native code using the JIT compiler at runtime. There is one more way of compiling the MSIL to native code as discussed below.



Services provided by the CLR

During execution, the CLR which is the runtime environment for .Net, provides services when the code is executing such as:

JIT Compiling	CLR provides the JIT compilers for the different CPU architectures.
Memory management	CLR provides garbage collector for managing the lifetime of objects. It also solves invalid memory references.
Security Management	Security in .NET is provided using the Code Access Security.
Exception Handling	CLR provides structured exception handling for catching the exceptions at runtime.
Cross language Integration	We can use the methods written in one language from a method written in a different language.

The Memory Management CLR provides the garbage collector for managing the lifetime of objects. It also solves invalid memory references.

Security Management Security in .NET is provided using the Code Access Security.

Exception Handling CLR provides structured exception handling for catching the exceptions at runtime.

Cross language Integration We can use the methods written in one language from a method written in a different language.

CLR provides two ways of compiling the MSIL to native code.

1. JIT Compiler
   
   The CLR provides a JIT compiler for each supported CPU architecture. JIT converts the MSIL to native code at application execution time. Instead of converting all the code in the assembly to native code, the JIT converts the MSIL to native code as needed during execution and stores the resulting native code in memory, so the next time the same code is executed it will be executed directly from memory instead of being compiled again.
   
   The resulting MSIL will run on every CPU for which JIT compiler exists (and it exists for most CPU's), but if the managed code calls platform specific API's then it will not run on other platforms.
   
   When the method is loaded the loader attaches a stub to each method. Once the native code is generated for the method, the stub is modified to point to the native code, so the next time the method is called the native code is executed directly.
   
2. Ngen.exe
   
   Normally methods in a managed code are just in time compiled and the compiled methods are thrown away once the the process running the code exits, therefore the method must be compiled again if it runs again.
   
   Secondly the compiled code cannot be shared across processes.
   
   Another drawback of the JIT approach is that it affects the runtime performance as it takes time to JIT compile the code.

The above drawbacks of the JIT compilation can be removed by using the NGen.exe tool. NGen referes to the compilation of the managed code prior to the execution of the code instead of the compilation of the code at run time.

It reduces application startup time by avoiding compiling the code at runtime. The second advantage is that the compiled code can be shared across processes.

This compiles an entire assembly at a time instead of a single method at a time. The compiled code is persisted on the disk so that it can be shared across the processes.