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.
.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.