This print for content only-size & color not accurate 7" X 9-1/4" / casebound / malloy

Single-File and Multifile Assemblies

In a great number of cases, there is a simple one-to-one correspondence between a .NET assembly

and the binary file (*.dll or *.exe). Thus, if you are building a .NET *.dll, it is safe to consider that

the binary and the assembly are one and the same. Likewise, if you are building an executable desk-

top application, the *.exe can simply be referred to as the assembly itself. As you’ll see in Chapter 15,

however, this is not completely accurate. Technically speaking, if an assembly is composed of a

single *.dll or *.exe module, you have a single-file assembly. Single-file assemblies contain all the

necessary CIL, metadata, and associated manifest in an autonomous, single, well-defined package.

Multifile assemblies, on the other hand, are composed of numerous .NET binaries, each of

which is termed a module. When building a multifile assembly, one of these modules (termed the

primary module) must contain the assembly manifest (and possibly CIL instructions and metadata

for various types). The other related modules contain a module-level manifest, CIL, and type meta-

data. As you might suspect, the primary module documents the set of required secondary modules

within the assembly manifest.

So, why would you choose to create a multifile assembly? When you partition an assembly into

discrete modules, you end up with a more flexible deployment option. For example, if a user is ref-

erencing a remote assembly that needs to be downloaded onto his or her machine, the runtime will

only download the required modules. Therefore, you are free to construct your assembly in such a

way that less frequently required types (such as a class named HardDriveReformatter) are kept in a

separate stand-alone module.

In contrast, if all your types were placed in a single-file assembly, the end user may end up

downloading a large chunk of data that is not really needed (which is obviously a waste of time).

Thus, as you can see, an assembly is really a 

logical grouping of one or more related modules that

are intended to be initially deployed and versioned as a single unit.

C H A P T E R   1