Introduction

If an assembly is in the .NET Framework Global Assembly Cache, then the compiled DLL is already on disk and can usually be copied out. What you cannot recover from the GAC is the original source project, build pipeline, or symbol history unless those artifacts were stored elsewhere. So the practical answer is: locate the assembly's physical path in the GAC, copy the DLL, and then use a decompiler if you need to inspect its contents.

First Clarify What the GAC Is

The GAC is a machine-wide store for shared .NET Framework assemblies. It is a deployment location, not a source-control system.

That means extracting from the GAC can give you:

• the compiled assembly file
• version and strong-name identity
• metadata you can inspect with tools

It does not give you:

• the original .csproj
• the full source code tree
• PDB files unless they were deployed separately

That distinction matters because many developers really mean "recover the original code," not "copy the DLL file."

Locate the Assembly in the GAC

On machines with the .NET Framework GAC, the assembly is stored under Windows system directories managed by the runtime. Typical locations include the GAC_MSIL, GAC_32, and GAC_64 folders under C:\Windows\Microsoft.NET\Assembly.

If you know the assembly name, gacutil is a practical way to locate it.

gacutil /l MyLibrary

That lists the strong-name identity of matching assemblies. From there, you can inspect the GAC folders directly.

A PowerShell example to search for a DLL by name:

Get-ChildItem 'C:\Windows\Microsoft.NET\Assembly' -Recurse -Filter MyLibrary.dll |
    Select-Object FullName

Once you find the file, you can copy it like any other DLL.

Copy the Assembly Out

After locating the physical file, copy it to a working directory:

Copy-Item \
  'C:\Windows\Microsoft.NET\Assembly\GAC_MSIL\MyLibrary\v4.0_1.2.3.4__31bf3856ad364e35\MyLibrary.dll' \
  'C:\Temp\MyLibrary.dll'

That gives you the compiled assembly outside the GAC. If the assembly is native-image related or accompanied by other files, copy only what you actually need for inspection or redistribution.

Use a Decompiler If You Need to Inspect It

If the real goal is to understand the code, the next step is usually decompilation. Tools such as ILSpy can open the extracted DLL and reconstruct readable C# from the Intermediate Language.

That workflow is:

1. copy the DLL out of the GAC
2. open it in a decompiler
3. inspect namespaces, types, and methods
4. export a reconstructed project only if needed

A decompiler is not perfect, but for managed assemblies it is often enough to understand logic, signatures, and dependencies.

Know the Limits

There are several important limits:

• obfuscated assemblies may decompile poorly
• release builds lose source comments and exact formatting
• generated C# may not match the original project structure
• strong-named identity does not guarantee you have the original vendor package

So extraction from the GAC is useful for analysis and recovery of the binary, but it is not the same as restoring the original development repository.

GAC Versus Modern .NET

This article is about the .NET Framework GAC model. Modern .NET does not use the GAC in the same way. If you are working with SDK-style .NET applications, package resolution usually comes from NuGet caches, application deployment folders, or runtime packs instead.

So before searching the GAC, verify that the target application actually uses the .NET Framework and shared GAC deployment.

A Safe Workflow

A practical, low-risk workflow is:

1. identify the assembly name and version
2. locate it with gacutil /l or a file search
3. copy the DLL to a temporary directory
4. inspect it with ILSpy or another analysis tool
5. avoid modifying files inside the GAC directly

That last point matters. The GAC is runtime-managed infrastructure, not a workspace for manual editing.

Common Pitfalls

The biggest mistake is expecting the GAC to contain the original source code. It contains deployed assemblies, not development history.

Another mistake is editing or deleting files directly inside the GAC directories. Use proper installation or uninstallation tools instead of manual mutation.

Developers also sometimes forget that the GAC applies to .NET Framework scenarios. If the application is built on modern .NET, searching the GAC may be irrelevant.

Finally, do not assume an extracted DLL is legally safe to redistribute or reverse engineer. Licensing and ownership still apply.

Summary

• You can usually extract the compiled DLL from the .NET Framework GAC by locating and copying its physical file.
• 'gacutil /l and PowerShell file search are practical ways to find the assembly.'
• The GAC stores binaries, not original source projects.
• Use a decompiler if your real goal is to inspect code.
• Avoid manual edits inside the GAC and verify that the target application actually uses the .NET Framework GAC model.