How do I find the PublicKeyToken for a particular dll?
Master System Design with Codemia
Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.
Introduction
The PublicKeyToken is part of a strong-named .NET assembly's identity. It helps the runtime distinguish one signed assembly from another during binding. The important caveat is that not every DLL has a PublicKeyToken. If the assembly is not strong-named, the token is absent.
What the PublicKeyToken Represents
A .NET assembly identity typically includes:
- simple name
- version
- culture
- public key token
The token is a compact identifier derived from the assembly's full public key. You see it in binding redirects, AssemblyName, and FullName strings.
Example assembly identity:
If the DLL is unsigned, the token is usually null or missing.
Quickest CLI Method: sn.exe
If you have the .NET SDK or developer tools that include the strong-name utility, use:
That prints the public key token if the assembly is strong-named.
This is the fastest answer on machines where the tool is already available.
PowerShell Method Without sn.exe
PowerShell can read the assembly name directly.
Why this is useful:
- no need to locate
sn.exe - works well in automation scripts
- reads the token from the assembly metadata directly
If the result is empty, the DLL probably is not strong-named.
Small C# Programmatic Example
If you need the token in application code, use AssemblyName.
This is useful when writing diagnostics or tooling around assembly loading.
If the DLL Is Already Loaded
When the assembly is already loaded in a process, you can inspect its full name directly:
The FullName output includes the PublicKeyToken when present.
How to Interpret a Missing Token
A missing token does not necessarily mean the DLL is broken. It usually means the assembly was not strong-name signed.
That matters because:
- unsigned assemblies do not participate in strong-name identity the same way
- binding redirects that mention a token are only relevant for signed assemblies
- the Global Assembly Cache historically relied on strong naming
So if you are troubleshooting assembly binding, first confirm whether the DLL is even expected to have a token.
When This Matters in Practice
You usually need the token when:
- writing or debugging binding redirects
- comparing two copies of a DLL with similar names
- inspecting references in legacy .NET Framework apps
- diagnosing load failures involving assembly identity mismatches
If the problem is only "which file is this," then name and version may already be enough. The token matters when strong-name identity is part of the equation.
Common Pitfalls
- Expecting every DLL to have a
PublicKeyTokeneven when it is unsigned. - Reading the assembly file name and assuming it reveals signing details.
- Using
sn.exeon a machine where the tool is not installed and concluding the DLL has no token. - Forgetting that
Assembly.FullNamealready exposes the token for loaded assemblies. - Treating a missing token as an application bug instead of a signing choice.
Summary
- A
PublicKeyTokenexists only for strong-named assemblies. - '
sn -T MyLibrary.dllis the fastest command-line method when available.' - PowerShell and
AssemblyName.GetAssemblyName()work well withoutsn.exe. - '
Assembly.FullNameshows the token for assemblies already loaded in memory.' - If the token is missing, the DLL is usually unsigned rather than malformed.

