Section 2.5. Assemblies

2.5. Assemblies

An assembly is a single .NET executable (EXE file) or library (DLL file). Since these file types existed before .NET was invented, why bother to give them a special name ? Well, it's not just the type of file; it's what is in the file that counts. (By the way, a .NET purist will insist that a single assembly can be split into multiple files. While this is true, it rarely happens, especially since it can't be done from within the Visual Studio development environment.)

An assembly is a unit of deployment ; that is, it's a file that can be deployed on a user 's system. .NET applications are made up of one or more assemblies , all working together for a common goal. Inside of an assembly, you find the following:

• The executable code of your application. Generally you will have a single primary EXE assembly, plus optional DLL assemblies.

• Embedded data, such as resources (graphics, strings, etc.).

• .NET-specific security permissions required for the assembly.

• The types (classes and so on) used in the assembly, including public classes that can be accessed by other assemblies (applications).

• Listings of the external types and references needed by the assembly, including references to other assemblies. These references also indicate the specific or minimum version number expected for those external components .

• Version information for the assembly. Assemblies include a four-part version number (major, minor, revision, and build, as in "2.1.0.25"), and this version number determines how the assembly interacts with other assemblies and components. .NET allows you to install different versions of an assembly on a single machine and have specific versions accessed by other applications. For instance, you may have Versions 1.0 and 2.0 of a spellchecking component installed on a workstation, one for an old word processor (that requires Version 1.0) and one for a newer email system (that uses Version 2.0). Both versions can reside on the same system without conflict. In fact, both versions can be actively running at the same time, a feature known as side-by-side execution .

Much of this information is stored in the assembly's metadata, which was discussed earlier. As a unit, this metadata is known as the assembly's manifest . Although this is somewhat repetitive, the manifest contains at least the following information.

• The name of the assembly

• Version information for the assembly

• Security information for the assembly

• A list of all files that are part of the assembly

• Type reference information for the types specified in the assembly

• A list of other assemblies that are referenced by the assembly

• Custom information, such as a user-friendly assembly title, description, company name, copyright information, and product information

If your application is split up into multiple assemblies, each assembly is only loaded into memory as it is needed. One interesting side effect of this as-needed access is that you can update an assembly file while the application that uses the file is still running . If you replace a DLL, the application will start using the new DLL the next time it has fully discontinued use of the old DLL. Of course, this generally happens when you exit and restart the application, but in some complex applications, you could perform a live update of an assembly.