An Overview of .NET Assemblies

Regardless of which .NET language you choose to program with, understand that despite the fact
that .NET binaries take the same file extension as COM servers and unmanaged Win32 binaries
(*.dll or *.exe), they have absolutely no internal similarities. For example, *.dll .NET binaries do
not export methods to facilitate communications with the COM runtime (given that .NET is not
COM). Furthermore, .NET binaries are not described using COM type libraries and are not registered
into the system registry. Perhaps most important, .NET binaries do not contain platformspecific
instructions, but rather platform-agnostic intermediate language (IL) and type metadata.

When a *.dll or an *.exe has been created using a .NET-aware compiler, the resulting module
is bundled into an assembly. You will examine numerous details of .NET assemblies in Chapter 15.
However, to facilitate the discussion of the .NET runtime environment, you do need to understand
some basic properties of this new file format.
As mentioned, an assembly contains CIL code, which is conceptually similar to Java bytecode
in that it is not compiled to platform-specific instructions until absolutely necessary. Typically,
“absolutely necessary” is the point at which a block of CIL instructions (such as a method implementation)
is referenced for use by the .NET runtime.
In addition to CIL instructions, assemblies also contain metadata that describes in vivid detail
the characteristics of every “type” living within the binary. For example, if you have a class named
SportsCar, the type metadata describes details such as SportsCar’s base class, which interfaces are
implemented by SportsCar (if any), as well as a full description of each member supported by the
SportsCar type.
.NET metadata is a dramatic improvement to COM type metadata. As you may already know,
COM binaries are typically described using an associated type library (which is little more than a
binary version of Interface Definition Language [IDL] code). The problems with COM type information
are that it is not guaranteed to be present and the fact that IDL code has no way to document
the externally referenced servers that are required for the correct operation of the current COM
server. In contrast, .NET metadata is always present and is automatically generated by a given .NETaware
compiler.
Finally, in addition to CIL and type metadata, assemblies themselves are also described using
metadata, which is officially termed a manifest. The manifest contains information about the current
version of the assembly, culture information (used for localizing string and image resources),
and a list of all externally referenced assemblies that are required for proper execution.