Datasheet

An assembly is completely self-describing and is a logical rather than a physical unit, which means that

it can be stored across more than one file (indeed dynamic assemblies are stored in memory, not on file

at all). If an assembly is stored in more than one file, there will be one main file that contains the entry

point and describes the other files in the assembly.

Note that the same assembly structure is used for both executable code and library code. The only real

difference is that an executable assembly contains a main program entry point, whereas a library assembly

doesn’t.

An important characteristic of assemblies is that they contain metadata that describes the types and methods

defined in the corresponding code. An assembly, however, also contains assembly metadata that describes

the assembly itself. This assembly metadata, contained in an area known as the manifest, allows checks

to be made on the version of the assembly, and on its integrity.

ildasm, a Windows-based utility, can be used to inspect the contents of an assembly, including the man-

ifest and metadata. ildasm is discussed in Chapter 16, “Assemblies.”

The fact that an assembly contains program metadata means that applications or other assemblies that

call up code in a given assembly do not need to refer to the registry, or to any other data source, in order

to find out how to use that assembly. This is a significant break from the old COM way of doing things,

in which the GUIDs of the components and interfaces had to be obtained from the registry, and in some

cases, the details of the methods and properties exposed would need to be read from a type library.

Having data spread out in up to three different locations meant there was the obvious risk of something

getting out of synchronization, which would prevent other software from being able to use the compo-

nent successfully. With assemblies, there is no risk of this happening, because all the metadata is stored

with the program executable instructions. Note that even though assemblies are stored across several files,

there are still no problems with data going out of synchronization. This is because the file that contains

the assembly entry point also stores details of, and a hash of, the contents of the other files, which means

that if one of the files gets replaced, or in any way tampered with, this will almost certainly be detected

and the assembly will refuse to load.

Assemblies come in two types: shared and private assemblies.

Private Assemblies

Private assemblies are the simplest type. They normally ship with software and are intended to be used

only with that software. The usual scenario in which you will ship private assemblies is when you are

supplying an application in the form of an executable and a number of libraries, where the libraries con-

tain code that should only be used with that application.

The system guarantees that private assemblies will not be used by other software, because an application

may only load private assemblies that are located in the same folder that the main executable is loaded

in, or in a subfolder of it.

Because you would normally expect that commercial software would always be installed in its own

directory, this means that there is no risk of one software package overwriting, modifying, or accidentally

loading private assemblies intended for another package. Because private assemblies can be used only

by the software package that they are intended for, this means that you have much more control over

Part I: The C# Language

24727c01.qxd:WroxPro 5/7/07 12:12 PM Page 18