2.You then compile it using the C# compiler (csc.exe) into an EXE.
3.The C# compiler outputs the MSIL code and a manifest into a read-only part of the EXE that has a standard PE (Win32-portable executable) header. So far, so good. However, here's the important part: when the compiler creates the output, it also imports a function named _ CorExeMain from the .Net runtime.
4.When the application is executed, the Operating system loads the PE, as well as any dependent dynamic-link librarIEs (DLLs), such as the one that exports the _ CorExeMain function (mscoree.dll), just as it does with any valid PE. 5.The Operating system loader then jumps to the entry point inside the PE, which is put there by the C# compiler. Once again, this is exactly how any other PE is executed in Windows. However, since the Operating system obviously can't execute the MSIL code, the entry point is just a small stub that jumps to the _ CorExeMain function in mscoree.dll.
6.The _ CorExeMain function starts the execution of the MSIL code that was placed in the PE.
7.Since MSIL code cannot be executed directly—because it's not in a machine-executable format—the CLR compiles the MSIL by using a just-in-time (JIT) compiler (or JITter) into native CPU instructions as it processes the MSIL. JIT compiling occurs only as methods in the program are called. The compiled executable code is cached on the Machine and is recompiled only if there's some change to the source code.
