Global Assembly Cache

Requirements

Assemblies residing in the GAC must adhere to a specific versioning scheme which allows for side-by-side execution of different code versions. Specifically, such assemblies must be strongly named.

Usage

There are two ways to interact with the GAC: the Global Assembly Cache Tool (gacutil.exe) and the Assembly Cache Viewer (shfusion.dll).

Global Assembly Cache Tool

gacutil.exe is an older command-line utility that shipped with .NET 1.1 and is still available with the .NET SDK.

One can check the availability of a shared assembly in GAC by using the command:

gacutil.exe /l <assemblyName>

One can register a shared assembly in the GAC by using the command:

gacutil.exe /i <assemblyName>

Or by copying an assembly file into the following location:

%windir%assembly

Note that for .NET 4.0 the GAC location is now:

%windir%Microsoft.NETassembly

Other options for this utility will be briefly described if you use the /? flag, i.e.:

gacutil.exe /?

Assembly Cache Viewer

The newer interface, the Assembly Cache Viewer, is integrated into Windows Explorer. Browsing %windir%assembly (for example, C:WINDOWSassembly) or  %WINDIR%Microsoft.NETassembly, displays the assemblies contained in the cache along with their versions, culture, public key token, and processor architecture. Assemblies are installed by dragging and dropping and uninstalled by selecting and pressing the delete key or using the context menu.

With the launch of the .NET Framework 4, the Assembly Cache Viewer shell extension is obsolete.

Example of use

A computer has two CLI assemblies both named AssemblyA, but one is version 1.0 and the other is version 2.0. Since it is required that both be compiled to a file named AssemblyA, they cannot exist in the same directory within the FAT32 file system. Instead, the virtual file system of the GAC can be used by programs that need to use each version of the assembly specifically.

Implementation

The GAC as a construct does not actually exist within the Windows OS. It is implemented and managed by the CLI. The folders within %systemroot% named assembly and Microsoft.NETassembly (for .NET 4.0) contain all globally available assemblies with managed filenames so that the version and public key tokens can be included. Each version can therefore exist within the same location and be called without requiring subsequent versions to preserve code entry point locations as usual. Windows Explorer allows the drag-and-drop installation of assemblies into this folder only if they would otherwise be permitted to be installed from the command line.

A calling application may specify a version of an assembly when referencing it, so the run-time can simply refer to the filename to use the correct one.

Pitfalls

The Global Assembly Cache mechanism helps to avoid older DLL hell, but it still has some drawbacks, such as:

By default, applications will only run with the version of the .NET Framework used to compile it, which can cause the application to fail on machines with newer versions of the .NET Framework installed — even when the application would normally run properly with the newer version.

It is sometimes necessary to use conditional compilation if some of the core .NET calls (used in the application) are only supported for some versions of the framework.

.NET applications that rely on native code risk incompatibilities, even with the GAC mechanism.

Every assembly that is added to the GAC must be strongly named. The process of making an assembly "strongly named" can be quite painful in some situations. For example, if an assembly depends on another assembly that is not strongly named, it cannot be registered in the GAC. In cases where the code of the third-party assembly is not in the programmer's possession, transforming the assembly to be strongly named can in fact be impossible.

Browsing for files using standard Windows APIs doesn't allow selection of DLLs located under the "assembly" folder when Explorer is showing the user-friendly view of the GAC.