An extremely detailed (and i presume accurate) depictions of the “.NET Global Assembly Cache” : http://www.codeproject.com/Articles/4352/Demystifying-the-NET-Global-Assembly-Cache

Associated directories are

C:\Windows\assmebly
C:\Windows\assmebly\GAC
C:\Windows\assmebly\GAC_32
C:\Windows\assmebly\GAC_MSIL
C:\Windows\Microsoft.NET\assembly
C:\Windows\Microsoft.NET\assembly\GAC_32
C:\Windows\Microsoft.NET\assembly\GAC_MSIL

Quote:

By Jeremiah Talkar, 14 Jan 2004

Introduction

My first introduction to the .NET Global Assembly Cache (henceforth referred to only as the GAC) was during a Guerrilla .NET Course conducted by Develop Mentor a week after the .NET Framework Beta 1 Release. I was immediately fascinated by this magical and mysterious piece within the entire .NET puzzle (yes, .NET had been a puzzle to me for a very long time). While ordinary (Private) assemblies cohabit peacefully within their master’s (client executable’s) folder or sub-folders thereof, the highly sociable (Shared) assemblies, including the all important .NET System assemblies implementing the Framework Class Library, reside within this majestic abode called the GAC.

The primary purpose behind writing this article is to share my findings related to the GAC with the development community. The information presented herein is original and a direct result of my personal research. To the best of my knowledge, these details have not been covered in any .NET article or book.

Since references to Fusion occur throughout this article, it may be appropriate to clarify the significance of this name vis-à-vis the GAC. Fusion is the internal name of the project at Microsoft to eliminate the problems of sharing DLL code. The GAC was originally called the Fusion cache and is currently implemented within Fusion.dll.

also:

The Basics

For the benefit of those that are genuinely unaware of what the GAC is, I am providing this simple description which has been plagiarized from the online documentation:

Each computer wherein the common language runtime is installed has a machine-wide code cache called the Global Assembly Cache. This Global Assembly Cache stores .NET assemblies specifically designated to be shared by several applications on that computer.

As a general rule, the Windows Registry is considered legacy within .NET and XCOPY [meaning, you can XCOPY all files from developer to user without another “installer” -jvk] deployment is highly encouraged, which in turn implies building assemblies that are private to a program’s main executable. Yet, there is a definite need for a central repository for .NET System assemblies as well as other user created Shared assemblies and it is this very need which is addressed by the GAC. Refer to .NET Framework Developer’s Guide: Global Assembly Cache for the formal product documentation on this topic.

The Microsoft KB article Q315682 HOW TO: Install an Assembly into the Global Assembly Cache in Visual Studio .NET walks the uninitiated through the steps required to install a .NET assembly into the GAC. If it is not already obvious, a key point to note here is that once your application installs Assemblies in the GAC, it loses the benefits of XCOPY deployment as these assemblies (other than the .NET System Libraries) must be explicitly installed in the GAC.

While covering the basics, it is important to understand the concept of Identity as it pertains to a .NET Assembly. An Assembly’s identity includes its simple textual name, a version number, an optional culture if the assembly contains localized resources, and an optional public key used to guarantee name uniqueness and to protect the name from unwanted reuse (name spoofing). An assembly with a simple Identity includes just the mandatory simple textual name and version number components. Since the GAC is the machine-wide repository for shared assemblies, it is very easy to run into the problem of name collisions if these assemblies only had simple identities because they are developed independently by different vendors and even developers within your own organization. Hence it is mandatory that every shared assembly installed in the GAC have a Strong Name. The formal definition of the term in the online documentation is …

Refer to Strong-Named Assemblies and Creating and Using Strongly-named assemblies for the details around strongly-named assemblies.

more:

The Public and not so public faces of the GAC

In order for the GAC to be useful, we need to be able to interact with it. I am aware of the following five interfaces available for such interaction.

1. The Windows Installer 2.0
2. The command line tool GACUtil.exe
3. The Windows Shell namespace extension implemented in SHFusion.dll
4. The .NET Framework Configuration Administrative tool
5. Programmatically accessing the GAC through APIs

Each of these is explored in detail within the following sections. The GAC itself is implemented as a hierarchy of directories. When using these interfaces to interact with the GAC, we are isolated from the implementation details of the GAC (which by-the-way is a good thing).\

 

…

thanks for reading 🙂