What is 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 desktop
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 metadata.
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 referencing
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.