Compilation Process in .Net

Under Microsoft .NET, applications are created using one or more high-level programming languages, such as VB.NET, C#, and COBOL .NET. Each .NET-compliant language goes through an initial compilation step that takes it from source-level code to the lowest common denominator language for .NET, Microsoft Intermediate Language (MSIL). MSIL is itself a full-fledged, object-aware language, and it's possible to build applications using nothing but MSIL. For a whirlwind tour of MSIL, see "Check under the MSIL hood to see how the CLR is running." An application stays in MSIL form until it's executed, at which time it is just-in-time (JIT) compiled into native code. Figure A illustrates this process.

Figure A

.NET's compilation process, from source to native instructions

JIT compilation occurs at the assembly level whenever an assembly is first loaded. (For more on assemblies, see "Introducing the assembly—a cure for 'DLL Hell'?".) When a reference to an object is first encountered, the JITer loads a stub for each method that matches that method's declaration. When a method is later invoked, the IL for it is compiled and the stub is replaced with the address of the method's compiled code. This happens each time a method is invoked for the first time, and the resulting native code is cached so that it can be reused the next time the assembly is loaded during that session. Obviously, this execution system results in more required overhead than that for a traditional compiled language, but not as much as you'd think.

That should clear up one common misconception: that .NET applications are interpreted. Another common misconception is that the JIT compiled code is stored on disk and reused for subsequent executions of the same application. While it's possible to do so, as you'll see shortly, this is not the default arrangement. The IL code for an application is recompiled into native code each time that application is run.