According to the ".NET Framework Developer's Guide," the managed execution process includes the following steps:
Figure 10.1 depicts this .NET compilation process in graphical form. Figure 10.1. .NET compilation process.
The .NET applications are developed with a high-level language, such as C# or VB.NET. The next step is to compile this code into MSIL. MSIL is a full-fledged, object-aware language, and it's possible (but unlikely an analogy might be to write an application in an assembly language) to build applications using nothing but MSIL. The JIT Compiler (aka jitter) occurs at the assembly level. JIT compilation takes into account the fact that some code might never be called during execution. Rather than using time and memory to convert all the MSIL in a portable executable (PE) file to native code, it converts the MSIL as needed during execution and stores the resulting native code so that it is accessible for subsequent calls. Sometimes people confuse JIT compiling for "building," but it is only the bold text in Figure 10.1 that the build team really cares about. This JIT compiling is what makes .NET rather unique and sometimes confusing when compared to unmanaged code builds. In the old world of building you would just compile and link everything into an executable binary and then ship the binary or binaries. In the .NET or Web services world, you ship "assemblies" that need to be JIT compiled or "assembled" by the .NET Framework. Note that the compilers for the .NET languages are included free with the .NET Framework. In addition, the C++ compiler is now free. Also notice that there is no concept of "linking" in .NET. Instead, code gets linked dynamically in the "runtime" platform that .NET provides. |