Learning Windows Server 2003

9.6. Assemblies

Assemblies are file-based units of compiled code that compose .NET applications. An assembly can be an executable or library, named with the extension .EXE or .DLL, respectively.

You are probably thinking, "Hey, this sounds eerily familiar!" And it should. However, .NET has put quite a spin on things as they were, most notably eliminating the heartache associated with DLL hell. Two new options are provided, both without the complexity of traditional DLLs.

9.6.1. Private Assemblies

Private assemblies are designed to be deployed with a single application and shared with no other applications. They do not require signing or version information. Assemblies also do not need to be registered with the system; you can simply reference them by name. The runtime locates assemblies using a set of rules.

First, all <dependentAssembly> elements are loaded from the application configuration file. If the requested assembly is listed, the assembly is loaded from the location specified in the HRef attribute of the <codeBase> element. If this sounds a little complicated, don't worry about it. It's rare to have an assembly listed with this method in practice, but for the sake of completeness, I had to mention it.

Generally, we let the runtime do its job and probe for the assembly. The runtime uses the parameters listed in Table 9-5 to probe for the assembly. These parameters are mixed, matched, concatenated, appended, etc., until the runtime finds the assembly.

Using the examples in Table 9-5, the runtime would probe the following locations:

C:\Hello\Hello.DLL C:\Hello\Hello\Hello.DLL C:\Hello\en-US\Hello.DLL C:\Hello\en-US\Hello\Hello.DLL C:\Hello\declaredbin\Hello.DLL C:\Hello\declaredbin\Hello\Hello.DLL C:\Hello\declaredbin\en-US\Hello.DLL C:\Hello\declaredbin\en-US\Hello\Hello.DLL C:\Hello\programbin\Hello.DLL C:\Hello\programbin\Hello\Hello.DLL C:\Hello\programbin\en-US\Hello.DLL C:\Hello\programbin\en-US\Hello\Hello.DLL

Seems a little excessive, doesn't it? In reality, it is not. Usually the culture is neutral (not specified) and the declared and program binpaths are not specified, leaving only a fraction of the possibilities.

In web applications, the rules change a bit, and Microsoft doesn't do much to explain them. The Application Base becomes a bin directory off of the web application root. The rule is to place all assemblies in this directory, except for culture-specific assemblies which you should place in culture-named directories off of the bin directory.

9.6.2. Strong-Named Assemblies

Strong-named assemblies are intended to be used when more than a single application needs access to the assembly. They are used, for example, with the assemblies that contain the .NET Class Library. Strong-named assemblies contain several extension attributes to uniquely identify them:

Version

This isn't your father's versioning scheme. The new scheme, major.minor.build.release (e.g., 1.1.4322.201), gives more precision than other development environments, providing the required uniqueness.

Culture

This is used mostly when storing resources such as error messages. You can store an assembly for each culture, and only the assembly for the current culture is loaded into an application.

Public Key

This prevents Joe Schmoe from camouflaging his assemblies as the ones by Microsoft, or your company. Assemblies are signed with a protected private key and subsequently can be verified with this public key.

Microsoft learned a hard lesson with its previous DLL registration technique. The previous model allowed a DLL to be registered once per system, and allowed any installer to update the DLL with a new version. In a perfect world, this would be optimal as you could keep things fresh and optimized, possibly providing a boost to existing applications as they would use the new version of the DLL. In the real world, it caused disasters. New versions of DLLs could break compatibility, interfering with applications that were sitting idly, minding their own business! Microsoft even had to introduce a feature into Windows 2000, System File Protection (SFP), to prevent its system DLLs from being overwritten in this fashion.

.NET takes a different approach to system assembly management. Rather than an application storing the name of an assembly, and being handed whatever version exists on the system, applications now must identify the assembly's name, version, and public key. This ensures that an application will use only assemblies that it has been tested with.

These system-wide assemblies are stored in the Global Assembly Cache (GAC). Called "the gack," this feature is included for those who still can't seem to keep their hands to themselves. The GAC is located in the %SystemRoot%\assembly folder. Assemblies are physically copied into the GAC when registered, providing a safe store for the assembly. You can manage the GAC in several different ways. The most obvious is to browse to the folder within Windows Explorer. Figure 9-3 illustrates an example of what you might find in the GAC. Notice the Explorer shell extension displaying the extended attributes.

The Windows shell extension supports delete operations and add operations via drag-and-drop. You can find a similar GAC management console in the .NET Configuration MMC under Assembly Cache.

You also can manage the GAC from the command line with the gacutil.exe utility, if the .NET SDK is installed. Basic usage is as follows:

• To install an assembly:

  gacutil /I <assemblyname>.dll

• To remove an assembly:

  gacutil /U <assemblyname>.dll

• To list all assemblies:

  gacutil /L