Three ways to tell if a .NET Assembly is Strongly Named (or has Strong Name)

Here are several convenient ways to tell whether a .NET assembly is strongly named. (Note: I assume the form is “strongly named” is more correct than “strong named” since that’s the form used in the output of the sn.exe tool shown immediately below.)

Testing for Strong Name on Command Line or in a Script

You tell whether an Assembly/DLL has been successfully strong-named using the Strong Name Tool (sn.exe) (which can be found somewhere like here: C:\Program Files\Microsoft SDKs\Windows\v7.0A\bin\sn.exe) by running the following at the command line:

sn -vf System.Data.dll

Here are the results when running against a strongly named assembly, then one that is not strongly named.

C:\> sn -v C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.Data.dll

Microsoft (R) .NET Framework Strong Name Utility  Version 4.0.30128.1
Copyright (c) Microsoft Corporation.  All rights reserved.
Assembly 'C:\...\System.Data.dll' is valid

C:\> sn -v C:\WINDOWS\ismif32.dll

Microsoft (R) .NET Framework Strong Name Utility  Version 4.0.30128.1
Copyright (c) Microsoft Corporation.  All rights reserved.
C:\WINDOWS\ismif32.dll does not represent a strongly named assembly

Since the return value from sn.exe is 0 (zero) when the strong name is in place, and 1 (one) if not correctly strong named, you can test for this in a script by examining ERRORLEVEL, as in the following (put it into a text file called “sn-test.bat” for example and run as “sn-test foo.dll”):

@ echo off

if "%1"=="" goto END
sn -q -vf %1 > NUL
if ERRORLEVEL 1 goto NOT_STRONG

:STRONG
echo Has strong name: %1
goto END

:NOT_STRONG
echo Not strong named: %1
goto END

:END

Note that this will tell you whether it has SOME strong name, but does not tell you which one. So this technique is not appropriate for all uses, but might help in, say, an automated script that checks your about-to-be-released assemblies to make sure you remembered to add the strong names to them. (See note below – “Strong Names not for Security”.)

If you need finer-grain control and wish to write low-level code to ascertain the strong-naming status of an assembly, you can do that too.

Viewing Strong Name Details with Reflector

You can load an assembly in RedGate’s .NET Reflector and quickly see the strong name details – or lack thereof for non-strong named assemblies. In the image below, see at the bottom where the strong name string is highlighted. Note that the strong name has four components:

1. Assembly name (“System.Data” in case of assembly “System.Data.dll”)
2. Assembly version (“2.0.0.0″ in case of “System.Data.dll”)
3. Culture (“neutral” in case of “System.Data.dll”)
4. PublicKeyToken (“b77a5c561934e089″ in case of “System.Data.dll”)

In the next image, see at the bottom where the LACK OF complete name string is highlighted; this assembly does not have a strong name to display, so “Name” field includes a null value for PublicKeyToken.

While you are at it… make Reflector the default program for” launching”  assemblies (actually would need to be for all files ending in the .DLL extension, but Reflector is smart enough to not choke on non-.NET assemblies).

Viewing Strong Name with Windows Explorer

Windows Explorer will not show you the strong name characteristics of an assembly, with one exception – for assemblies in the Global Assembly Cache (GAC), strong name data is included in the Properties dialog. But if  you are examining the GAC, this can be handy.

Windows Explorer (at least on Windows 7) will show you Digital Signatures when present – do not confuse these with Strong Names…

Strong Names Not for Security

Finally, a word of caution… Strong names are about versioning, not about security. Strong names are more about avoiding DLL Hell (which is largely an accidental concern) than about avoiding hackers. Strong names can be hacked, and Microsoft emphasizes that  strong-named assemblies do not give the same level of trust as digitally signing:

Strong names provide a strong integrity check. Passing the .NET Framework security checks guarantees that the contents of the assembly have not been changed since it was built. Note, however, that strong names in and of themselves do not imply a level of trust like that provided, for example, by a digital signature and supporting certificate.

Consider digitally signing your .NET assemblies if it is important to you or your customers that the origin of the assemblies be traceable and verifiable.

Many .NET developers know and love the .NET Reflector tool. If you are one of them, consider making Reflector the default action for when you double-click on (i.e., open) a .DLL file. Just like assigning Microsoft Word to open .DOC files, you can assign a program to open your .DLL files. It is easy… Here are the instructions for Windows 7 – for other versions of Windows the process is similar.

1. Download Reflector and install it; remember where it is installed

2. Using Windows Explorer, navigate to any DLL file on your computer

3. Right-click on the DLL and select “Open with…” from the popup menu

4. From the Caution dialog that appears, select “Open with…” (yes, you have to select it twice, once in step 3, again in step 4):

5. From the dialog that appears, choose the second option – “Select a program from a list of installed programs”:

6. Now you will simply need to choose  the “Browse…” button and navigate to wherever it is you installed Reflector.exe, click the “Open” button and you are done.

Now whenever you want to examine a DLL in Reflector, you can double-click on it from Windows Explorer. If you tool around in the command line like I sometimes will do, you can also launch the DLL in Reflector by just “running” it from the command line like you might do for a .txt document to open it in Notepad.

Realize that Reflector can’t do much with a DLL that is not actually a .NET Assembly, but will handle that case gracefully.