The Common Language Runtime
At the heart of the .NET Framework is the common language runtime. The common language runtime is responsible for providing the execution environment that code written in a .NET language runs under. The common language runtime can be compared to the Visual Basic 6 runtime, except that the common language runtime is designed to handle all .NET languages, not just one, as the Visual Basic 6 runtime did for Visual Basic 6. The following list describes some of the benefits the common language runtime gives you:
Automatic memory management
Cross-language debugging
Cross-language exception handling
Full support for component versioning
Access to legacy COM components
XCOPY deployment
Robust security model
You might expect all those features, but this has never been possible using Microsoft development tools. Figure 1.3 shows where the common language runtime fits into the .NET Framework.
Figure 1.3. The common language runtime and the .NET Framework.
Note
Code written using a .NET language is known as managed code. Code that uses anything but the common language runtime is known as unmanaged code. The common language runtime provides a managed execution environment for .NET code, whereas the individual runtimes of non-.NET languages provide an unmanaged execution environment.
Inside the Common Language Runtime
The commonlanguage runtime enables code running in its execution environment to have features such as security, versioning, memory management, and exception handling because of the way .NET code actually executes. When you compiled Visual Basic 6 forms applications, you had the ability to compile down to native node or p-code. Figure 1.4 should refresh your memory of what the Visual Basic 6 options dialog looked like.
Figure 1.4. Visual Basic 6 compiler options dialog.
When you compile your applications in .NET, you aren't creating anything in native code. When you compile in .NET, you're converting your code—no matter what .NET language you're using—into an assembly made up of an intermediate language called Microsoft Intermediate Language (MSIL or just IL, for short). The IL contains all the information about your application, including methods, properties, events, types, exceptions, security objects, and so on, and it also includes metadata about what types in your code can or cannot be exposed to other applications. This was called a type library in Visual Basic 6 or an IDL (interface definition language) file in C++. In .NET, it's simply the metadata that the IL contains about your assembly.
Note
The file format for the IL is known as PE (portable executable) format, which is a standard format for processor-specific execution.
When a user or another component executes your code, a process occurs called just-in-time (JIT) compilation, and it's at this point that the IL is converted into the specific machine language of the processor it's executing on. This makes it very easy to port a .NET application to any type of operating system on any type of processor because the IL is simply waiting to be consumed by a JIT compiler.
Note
The first time an assembly is called in .NET, the JIT process occurs. Subsequent calls don't re-JIT the IL; the previously JITted IL remains in cache and is used over and over again. On Day 5, “Writing ASP.NET Applications,” you learn more about the JITting process and how it can affect your ASP.NET applications. On Day 19, “Understanding Microsoft Application Center Test,” when you learn about Application Center Test, you also see how the warm-up time of the JIT process can affect application performance.
Understanding the process of compilation in .NET is very important because it makes clear how features such as cross-language debugging and exception handling are possible. You're not actually compiling to any machine-specific code—you're simply compiling down to an intermediate language that's the same for all .NET languages. The IL produced by J# .NET and C# looks just like the IL created by the Visual Basic .NET compiler. These instructions are the same, only how you type them in Visual Studio .NET is different, and the power of the common language runtime is apparent.
When the IL code is JITted into machine-specific language, it does so on an as-needed basis. If your assembly is 10MB and the user is only using a fraction of that 10MB, only the required IL and its dependencies are compiled to machine language. This makes for a very efficient execution process. But during this execution, how does the common language runtime make sure that the IL is correct? Because the compiler for each language creates its own IL, there must be a process that makes sure what's compiling won't corrupt the system. The process that validates the IL is known as verification. Figure 1.5 demonstrates the process the IL goes through before the code actually executes.
Figure 1.5. The JIT process and verification.
When code is JIT compiled, the common language runtime checks to make sure that the IL is correct. The rules that the common language runtime uses for verification are set forth in the Common Language Specification (CLS) and the Common Type System (CTS).