Teach Yourself Visual Studio® .NET 2003 in 21 Days [Electronic resources] نسخه متنی

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.

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.

When you compile 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 codeyou'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.

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).