What Is the Common Language Runtime?

The first misnomer to point out is that code compiled for .NET is not interpreted as it is with Java and the Java Virtual Machine. (Java code using the latest version of J2SE or J2EE can now, in fact, be JIT-compiled.) Rather, all compilers for .NET emit special code known as Intermediate Language or IL. The Common Language Runtime performs just-in-time compilation to native code as needed. This allows for increased code performance and the ability to verify the managed code. Figure 2.1 depicts a visual representation of layers that make up the Common Language Runtime.

Figure 2.1. Layers of the Common Language Runtime.

The Common Language Runtime provides several benefits over traditional unmanaged code. A subset of these benefits includes the following:

• Performance improvements including memory management, code optimization, and security

• The ability to reuse components developed in other languages

• Cross language inheritance of classes

• Garbage collection

• Allow for compiler writers to target IL rather than a specific CPU or operating system

• Metadata for assemblies

• Unified threading model

• Relief from DLL hell

Multiple Languages, One Runtime

Because the runtime understands only IL, any language can be targeted to execute on the .NET platform. As long as a target language complies with the common language specification (CLS), cross-language development is not hindered by data types, object references, memory management, or threading models. The Common Language Runtime provides the infrastructure for which all languages can take advantage of. Currently, there are more than 20 languages for .NET.

Isolation

Another major advantage that the Common Language Runtime offers is application isolation. This isolation allows for security and stability. Through the use of AppDomains (isolated execution apartments), if a .NET application becomes unstable, it will not have any effect on other applications executing within the Common Language Runtime or on the operating system itself. This protection has been a long sought-after need for Windows applications.

AppDomains also protect applications from each other by preventing memory overwrites and malicious attacks on executing applications. The AppDomain provides a boundary that protects the executing application from outside interference.

As you will see in an upcoming chapter, AppDomains are also valuable for many other reasons, including hosting plug-in DLLs that can extend the functionality of your application.

Platform Invoke

Another benefit of the Common Language Runtime is the concept of PInvoke, which is the ability of .NET applications to invoke the Win32 API when necessary. The Common Language Runtime provides a type-marshalling system for converting between .NET types (such as string) to Win32-native types (such as char* [a character pointer]). Any Win32 API method can be imported with a simple declaration such as the following:

 using System.Runtime.InteropServices;  public class MyWin32Wrapper {    [DllImport( "User32.dll" )]    static public extern void Beep( int frequency, int duration );  } 

Code Access Security

To protect OS resources, access permissions, and execution security, the Common Language Runtime implements artifact-based security. Not only can permissions be limited to users, but an assembly (a compiled .NET component), can be restricted based on metadata held within it. This allows for restrictions to be placed on the execution of the assembly regardless of the user's system privileges.

The security system also examines the source of the IL. Code from the local machine has a higher security privilege than code being executed from a remote share. Such security prevents remote execution of nontrusted application code.

Security was built into .NET from the ground up. In Windows XP and beyond, even the application loader recognizes .NET applications and performs preliminary security validations to ensure that the assembly was not modified before handing over execution to the Common Language Runtime itself.

The JIT Compiler

Traditional compiler implementers were left to handle code optimization based on target CPU, execution prediction, register allocation, code unwinding, and so on. With .NET and the Common Language Runtime, compilers that target the .NET platform need to be concerned only with emitting IL. The Common Language Runtime invokes a JIT (just-in-time) compiler as needed for the execution of the IL. The JIT compiler is optimized to handle loop unrolling, caching nonvolatile variables, and optimizing execution flow among other things.

Code Execution

Execution of IL works by first determining whether the method/code to be executed has already been compiled; if not, the IL is JIT compiled, cached, and executed. If the IL segment has already been compiled, the cached native code is executed. In essence, an application will execute faster the second time a section of code is executed.

COM Interoperability

The ability to leverage components is key to the .NET Framework. Before .NET, COM was the lingua franca of component development and reuse. The Common Language Runtime supports COM component use via an interop layer in which a runtime-callable wrapper is created. This managed wrapper hides the complexities of dealing with traditional COM development and component usage. No longer do developers need to know about GUIDs, IUnknown, IDispatcher, and the ambiguous VARIANT type. The managed wrapper handles type conversion, interface querying, and connection points and translates them to .NET types, interfaces, and events. All the grunt work is taken care of for the developer.

Along with the ability to consume classic COM components, the Common Language Runtime also provides a mechanism to expose a newly created .NET component as a classic COM object. COM clients such as VB 6 can consume these .NET components in the same manner as a classic COM object. To accomplish this task, a COM-callable wrapper is created. This wrapper handles intercepting calls to IUnknown and IDispatch. In addition, the type marshaller is used to convert .NET types to COM types. It's important to note that not all .NET constructs have a COM equivalent.

COM does not support static methods, polymorphism, or data types not specified by the COM standard.

Rotor: Microsoft's Shared Source Common Language Infrastructure

To round out the discussion about the Common Language Runtime, the ultimate reference is Rotor. Rotor is a shared source implementation of the common language infrastructure (CLI). Its goal is to provide students, professors, and professionals with an insight into the development of tools targeted at .NET. Rotor can be downloaded from the Microsoft website.