What Is an Assembly?

As I already mentioned in Chapter 1, "Introducing.NET," an assembly is a "unit of deployment," which in most cases is just a file. An assembly is a repository for compiled .NET application code; any code you write will eventually be stored in some EXE file (if it is an application) or DLL file (for code libraries or extensions to an application). Everything that .NET needs to know to load and run your application is stored in the assembly.

Assemblies are either private or public. Private assemblies are designed for use in a single application only. If there aren't any DLLs, then an EXE assembly is the application. Private assemblies appear in their own directory, the installation directory of the application or library. You can run two different private assemblies at the same time, and they won't bother each other. This is true even if each assembly uses the same combination of namespace and class names for its coded elements. If two application assemblies each implement a class named WindowsApplication1.Class1, they will not interfere with each other when running; they are private, and private means private.

Public assemblies are designed for shared use among multiple .NET applications. Public assemblies differ from private assemblies in two major ways.

1. Public assemblies have a strong name, an encrypted digital signature that is attached to an assembly to guarantee that it came from its named vendor or source. It's built from the assembly's name, version number, culture information, a "public key," and a digital signature generated from the assembly file that contains the manifest (described later). The .NET Framework includes a Strong Name generation tool (sn.exe) that assists in this process, and Visual Studio includes options that let you add a digital signature during the compilation process. (It's on the Signing tab of the project's properties.)

   The strong name of an assembly should be (and better be) unique; if two assemblies share a common strong name, they are copies of the same assembly. You can add a strong name to any assembly, even private assemblies.

2. Public assemblies are stored in the global assembly cache (GAC). Although you can put a copy of your shared component in your application's install directory, it will only truly be shared once it reaches the GAC directory. The GAC lives in a directory named "assembly" within the computer's Windows directory. (On my system, it's in c:\windows\assembly.) Once a .NET assembly has a strong name applied, you can add it to the GAC by either dragging the file into the assembly directory, or by using the Global Assembly Cache Tool (gacutil.exe). Don't worry about your file being lonely if it's not communing with your other installed files. On my freshly installed copy of .NET, I found over 500 files already in the GAC directory, including all of the DLLs for the Framework Class Libraries.

.NET lets you install multiple versions of an assembly on a system and use them at the same time (a process called versioning). This applies both to applications (EXE) and libraries (DLL), and to private assemblies and shared assemblies in the GAC. Don't believe me? Open up the GAC's assembly folder, set the Explorer folder to a Details view, and then sort by Assembly Name. If you scroll down, you'll see the same file show up multiple times. Figure 5-1 shows a part of the cache. There are two copies of System.Data listed (from the System.Data.dll file), one for version 2.0 of the .NET Framework, and one for an older version. There are also several related System.Data.resources files, each one for a different language.

Figure 5-1. The GAC has this duplication under control

Although there is usually a one-to-one relationship between files and assemblies, there may be cases when an assembly is made up of multiple files. For instance, an application might include an external graphics file in its assembly view. .NET keeps a close watch on these files. If any of the files are modified, deleted, or otherwise maimed, you will hear about it. For the purposes of discussion, the rest of this chapter only considers single-file assemblies.