Assemblies, Manifests, Metadata, and Modules
Different .NET-compliant language compilers produce MSIL (Microsoft Intermediate Language) along with metadata, which describes the types in your code. Following are the functions of metadata:
Describes and references the datatypes defined by the VOS (Virtual Object System) type system
Lays out instances of classes in memory
Resolves method invocation
Solves versioning problems (DLL hell)
The Microsoft Intermediate Language and metadata are packed into an executable format called a portable executable file (PE file), which extends PE and the Common Object File Format (COFF). COFF enables the operating system to recognize Common Language Runtime (CLR). One great advantage of packing metadata along with the MSIL is that it enables your code to describe itself, thus eliminating the need for type libraries or Interface Definition Language (IDL).
Assemblies, modules, and manifests are grouping constructs, each playing a different role in the CLR environment.
An assembly is more of a logical entity than a physical entity. Hence, it can be used in multiple files. It contains the CLR targeted code compiled by different language compilers. An assembly is a completely self-describing unit, which can be thought of as .dll or .exe. If the Portable executable doesn't contain the associated assembly manifest, it doesn't get executed and moreover there will be one and only one entry point for an assembly. Following are the some of the functions of the assemblies:
It acts as a boundary for all sort of security, types, reference library, and versioning requests.
It's the deployment unit. On the initialization of an application, assemblies of an application must be present and others could be called on demand.
It makes side-by-side deployment possible.
A manifest is basically an area of metadata occupied in an assembly that allows checks to be made on the version of the assembly. It also checks for the integrity of an assembly.
A module contains the file format of an executable. If the module contains a manifest, it becomes an assembly as well as a module. There will be one and only one manifest in all of the files. The relationship between assembly, module, and files can be visualized from the diagram in Figure 2.
Figure 2 Assembly-Module-File relationship.
Having seen how assembly, module, and files communicate with each other, let's look into the sequence of the declaration followed while writing the IL programs:
.assembly .assembly extern .class .class extern .corflags .custom .data .field .file .mresource .method .module .module extern .subsystem <externSourceDecl> <securityDecl>
I hope that this overview gives you the initial confidence required to start writing intermediate language programs. The subject is not as simple as it seems. ECMA documents contain complete information about this language. We'll try to probe more into this subject in coming articles.