GAC - Introducing the Global Assembly Cache in .NET Framework

Introduction

The Global Assembly Cache (GAC) was a core concept in the early .NET Framework era. It provided a central, machine-wide location for storing and sharing strongly named assemblies across multiple applications on the same server. Understanding how the GAC works is still useful today if you maintain or troubleshoot legacy .NET Framework applications.

Modern .NET (from .NET Core onward) has moved toward application-local dependencies and side-by-side deployment, but the GAC remains part of many production environments that run classic ASP.NET and Windows Forms applications.

What is the Global Assembly Cache?

The Global Assembly Cache is a machine-wide code cache that lives under the Windows system directory. When an assembly is placed in the GAC, it becomes available to any .NET Framework application on that machine, provided the application references the assembly by its strong name. This avoids copying the same DLL into multiple bin or application folders.

To be stored in the GAC, an assembly must be strongly named. A strong name includes the assembly's friendly name, version, culture, and a public key token. This identity allows the runtime to uniquely locate the correct assembly and prevents accidental conflicts between different versions or vendors.

When should you use the GAC?

It is tempting to place every assembly into the GAC, but that is rarely a good idea. The original guidance from the .NET Framework era still holds: keep assemblies application-local unless you have a clear reason to share them.

Reserve the GAC for assemblies that:

• Are used by multiple applications on the same server.
• Have a stable, versioned public API that you intend to share.
• Need to be centrally managed by operations or administrators.

You do not need to install every assembly into the GAC just to make it accessible to COM interop or unmanaged code. In many cases, keeping dependencies within the application directory is safer and easier to deploy.

Installing assemblies into the GAC

There are several ways to install a strongly named assembly into the Global Assembly Cache in .NET Framework environments:

• Using a Windows Installer (MSI) or deployment package that is GAC-aware.
• Using the gacutil.exe SDK tool during development or on test machines.
• Using drag-and-drop operations in the legacy GAC shell view on older versions of Windows.

The recommended approach for production is an installer that supports GAC deployment. For quick testing or development, the SDK tool works well. The example below shows how to add and remove an assembly using gacutil:

gacutil /i MyCompany.Logging.dll

# Later, to remove the same assembly:
gacutil /u MyCompany.Logging

On modern systems you may also encounter PowerShell- or MSBuild-based deployment processes that automate GAC registration as part of a larger installation script.

Security and access control

In typical installations, the Global Assembly Cache resides under the Windows system directory (for example, %WINDIR%\assembly on older versions of Windows). As a result, it inherits the access control list (ACL) applied to that directory.

In a well-managed environment, only administrators or deployment accounts should have permission to add or remove assemblies from the GAC. This helps protect shared code from being accidentally or maliciously replaced. Treat GAC write access with the same care you would give to modifying system binaries.

Strong names and integrity checks

Every assembly in the GAC must be strong-name signed. When you add an assembly, the runtime uses the strong name to verify that the physical files match the expected identity. If the files are corrupted or tampered with, the verification step fails and the assembly is rejected.

As a best practice, always:

• Sign shared assemblies with a strong-name key pair.
• Version assemblies carefully so dependent applications can bind to the correct release.
• Avoid manually editing or patching DLLs that live in the GAC.

These integrity checks were designed to reduce the risk of conflicting or compromised code in the shared cache, especially on servers that host many applications.