CHAPTER 14 BUILDING AND CONFIGURING CLASS LIBRARIES
Source Code The VisualBasicCarClient project is located under the Chapter 14 subdirectory.
Understanding Private Assemblies
Technically speaking, the class libraries you’ve created thus far in this chapter have been deployed as
private assemblies. Private assemblies must be located within the same directory as the client application
that’s using them (the application directory) or a subdirectory thereof. Recall that when you set a
reference to CarLibrary.dll while building the CSharpCarClient.exe and VisualBasicCarClient.exe
applications, Visual Studio responded by placing a copy of CarLibrary.dll within the client’s
application directory (at least, after the first compilation).
When a client program uses the types defined within this external assembly, the CLR simply loads
the local copy of CarLibrary.dll. Because the .NET runtime does not consult the system registry when
searching for referenced assemblies, you can relocate the CSharpCarClient.exe (or
VisualBasicCarClient.exe) and CarLibrary.dll assemblies to a new location on your machine and run
the application (this is often termed Xcopy deployment).
Uninstalling (or replicating) an application that makes exclusive use of private assemblies is a nobrainer: simply delete (or copy) the application folder. More important, you do not need to worry that
the removal of private assemblies will break any other applications on the machine.
The Identity of a Private Assembly
The full identity of a private assembly consists of the friendly name and numerical version, both of
which are recorded in the assembly manifest. The friendly name is simply the name of the module that
contains the assembly’s manifest minus the file extension. For example, if you examine the manifest of
the CarLibrary.dll assembly, you find the following:
.assembly CarLibrary
{
...
.ver 1:0:0:0
}
Given the isolated nature of a private assembly, it should make sense that the CLR does not bother
to use the version number when resolving its location. The assumption is that private assemblies do not
need to have any elaborate version checking, as the client application is the only entity that “knows” of
its existence. Because of this, it is (very) possible for a single machine to have multiple copies of the same
private assembly in various application directories.
Understanding the Probing Process
The .NET runtime resolves the location of a private assembly using a technique called probing, which is
much less invasive than it sounds. Probing is the process of mapping an external assembly request to the
location of the requested binary file. Strictly speaking, a request to load an assembly may be either
implicit or explicit. An implicit load request occurs when the CLR consults the manifest in order to
resolve the location of an assembly defined using the .assembly extern tokens. For example:
// An implicit load request.
.assembly extern CarLibrary
526