The Architecture of the .NET Framework Development Platform

The Architecture of the .NET Framework Development Platform

Figure 1-1 shows the process of compiling source code files. As the figure shows, you can create source code files using any programming language that supports the CLR. Then you  use the corresponding compiler to check the syntax and analyze the source code. Regardless of which compiler you use, the result is a managed module. A managed module is a standard Windows portable executable (PE) file that requires the CLR to execute. In the future, other operating systems may use the PE file format as well.

PE header

The standard Windows PE file header, which is similar to the Common Object File Format (COFF) header. This header indicates the type of file: GUI, CUI, or DLL, and it also has a timestamp indicating when the file was built. For modules that contain only IL code, the bulk of the information in the PE header is ignored. For modules that contain native CPU code, this header contains  information about the native CPU code.

CLR header

Contains the information (interpreted by the CLR and utilities) that makes this a managed module. The header includes the  ersion of the CLR required, some flags, the MethodDef metadata token of the managed module’s entry point method (Main method), and the location/size of the module’s metadata, resources, strong name, some flags, and other less interesting stuff.

Metadata

Every managed module contains metadata tables. There are two main types of tables: tables that describe the types and  members defined in your source code and tables that describe the types and members referenced by your source code.

Intermediate language (IL)code

Code that the compiler produced as it compiled the source code. The CLR later compiles the IL into native CPU instructions.

Most compilers of the past produced code targeted to a specific CPU architecture, such as x86, IA64, Alpha, or PowerPC. All CLR-compliant compilers produce IL code instead. (I’ll go into more detail about IL code later in this chapter.) IL code is  ometimes referred to as managed code because the CLR manages its lifetime and execution.

In addition to emitting IL, every compiler targeting the CLR is required to emit full metadata into every managed module. In brief, metadata is simply a set of data tables that describe what is defined in the module, such as types and their members. In addition, metadata also has tables indicating what the managed module references, such as imported types and their members. Metadata is a superset of older technologies such as type libraries and interface definition language (IDL) files. The important thing to note is that CLR metadata is far more complete. And, unlike type libraries and IDL, metadata is always associated with the file that contains the IL code. In fact, the metadata is always embedded in the same EXE/DLL as the code, making it impossible to separate the two. Because the compiler produces the metadata and the code at the same time and binds them into the resulting

managed module, the metadata and the IL code it describes are never out of sync with one another.Metadata has many uses. Here are some of them:

§Metadata removes the need for header and library files when compiling since all the     information about the referenced types/members is contained in the file that has the IL     that implements the type/members. Compilers can read metadata directly from     managed modules.

§Visual Studio .NET uses metadata to help you write code. Its IntelliSense feature  parses metadata to tell you what methods a type offers and what parameters that  method expects.

§The CLR’s code verification process uses metadata to ensure that your code performs  only “safe” operations. (I’ll discuss verification shortly.)

§Metadata allows an object’s fields to be serialized into a memory block, remoted to     another machine, and then deserialized, re-creating the object and its state on the    remote machine.

§Metadata allows the garbage collector to track the lifetime of objects. For any object,    the garbage collector can determine the type of the object and, from the metadata,  know which fields within that object refer to other objects.