Managed Modules- Windows Portable Executable (PE)

The above diagram shows the resulting 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.

A Managed Module is composed of the following parts:

Part	Description
PE header	This is the standard Windows PE file header, which is similar to the Common Object File Format (COFF) header. The PE header indicates the type of file--GUI, CUI, or DLL—and also has a timestamp indicating when the file was built. For modules that contain only IL code (see below, Intermediate Language 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	This header contains the information (interpreted by the CLR and utilities) that makes this a managed module. It includes the version 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, of which there are 2 main types: those that describe the types and members defined in your source code, and those that describe the types and members referenced by your source code.
Intermediate Language (IL) Code	This is the code that was produced by the compiler as it compiled the source code. IL is later compiled by the CLR 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 intermediate language (IL) code instead. IL code is sometimes referred to as managed code, because its lifetime and execution are managed by the CLR.

Metadata is simply a set of data tables that describe what is defined in the module, such as types and their members. Also it 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 IDL files.

The important thing to note is that CLR metadata is far more complete than its predecessors. 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. Since the metadata and code are produced by the compiler at the same time and are bound 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, because all the information about the referenced types/members is contained in one file along with the IL that implements those type/members. Compilers can read metadata directly from managed modules.

· Visual Studio 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 code verification process uses metadata to ensure that your code performs only “safe” operations. Verification is discussed shortly.

· Metadata allows an object’s fields to be serialized into a memory block, remoted to another machine, and then deserialized, recreating 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 it knows which fields within that object refer to other objects.


Four of the compilers that Microsoft offers--C#, Visual Basic, JScript, and the IL Assembler--always produce managed modules, which require the CLR to execute. That is, end users must have the CLR installed on their machines in order to execute any managed modules. This situation is similar to the one that end users face with MFC or VB 6 applications:
they must have the MFC or VB DLLs installed in order to run them.


But as CLR works with assemblies[ a logical grouping of one or more managed modules or resource files] not with Modules. An assembly is the smallest unit of reuse, security, and versioning, produced as single file assembly or multi-file assembly depending on compilers/tools choice.

The figure below should help explain what assemblies are about:


A single file [managed modules and resource (or data) files] is passed to tools, producing a single PE file that represents the logical grouping of files. This PE file contains a block of data called the manifest, which is simply another set of metadata tables. These tables describe the assembly: the files that make it up, the publicly exported types implemented by the files in the assembly, and the resource or data files that are associated with it.