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. (English language note: I assume the form “strongly named” is preferred over “strong named” since that’s the form used in the output of the sn.exe tool shown immediately below.)
Towards the end, this post discusses use of Strong Names with Silverlight.
Then in the final section of this post the often confusing – though very important – differences between Strongly Named assemblies and Digitally Signed assemblies are clarified.
But first, here are three approaches for telling whether a .NET Assembly is Strongly Named...
Approach #1: 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.
Approach #2: Viewing Strong Name Details with IL DASM
Visual Studio ships with a handy utility – the Microsoft Intermediate Language Disassembler (ILDASM.EXE (tutorial)) – which can be used for disassembling .NET binaries to peruse the contents, perhaps for viewing the method signatures or viewing the .NET Assembly Manifest. It is helpful to load an assembly using IL DASM and examine the manifest to see whether there is a strong name key available. Your first step is to load the desired Assembly using the ildasm.exe utility. On my Windows 7 machine, IL DASM is found at
C:\Program Files\Microsoft SDKs\Windows\v7.0A\bin\ildasm.exe
and you can load up the System.Drawing.dll .NET Assembly as in the following example:
C:\> ildasm C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.Drawing.dll
Once loaded, you will see a screen like the one below.
Note the MANIFEST section highlighted. Double-click on MANIFEST which load the following screen of manifest-specific data:
Find the section for the Assembly you’ve loaded – in this case, System.Drawing and following the section (which is marked with the “.assembly System.Drawing” directive highlighted above, and the content begins with the opening brace (“{“) shown above, and ends with its matching brace later in the manifest, and shown below.
The highlighted part of the manifest is the public key for this assembly. This public key can also be seen using the sn.exe tool, as follows:
C:\> sn -Tp C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.Drawing.dll echo Not strong named: %1
Microsoft (R) .NET Framework Strong Name Utility Version 3.5.30729.1 Copyright (c) Microsoft Corporation. All rights reserved.
Public key is 002400000480000094000000060200000024000052534131000400000100010007d1fa57c4aed9 f0a32e84aa0faefd0de9e8fd6aec8f87fb03766c834c99921eb23be79ad9d5dcc1dd9ad2361321 02900b723cf980957fc4e177108fc607774f29e8320e92ea05ece4e821c0a5efe8f1645c4c0c93 c1ab99285d622caa652c1dfad63d745d6f2de5f17e5eaf0fc4963d261c8a12436518206dc09334 4d5ad293
Public key token is b03f5f7f11d50a3a
Note that the Public key in the output from sn.exe matches the highlighted public key in the image immediately above it (of course you should ignore the spaces between pairs of digits in the screen shot).
If an assembly is not strongly named, the Public key will be missing from the manifest and will not be displayed by sn -Tp command.
Since IL DASM comes with both Visual Studio and with the .NET SDK, it is already on the desktop for most .NET Developers, and is therefore sometimes the handiest tool. The third option, .NET Reflector, is a third-party tool, though one adopted by many .NET Developers due to its awesomeness. Reflector conveniently shows more details about the strong name.
Approach #3: Viewing Strong Name Details with Reflector
You can load an assembly in the free version 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 five parts (though the Culture is optional):
- Simple Name or Assembly name without the “.dll” extension (“System.Data” in case of assembly “System.Data.dll”)
- Assembly version (“2.0.0.0″ in case of “System.Data.dll”)
- Culture (“neutral” in case of “System.Data.dll”, but might be “en-us” for US English, or one of many others)
- Public Key or PublicKeyToken (public part of the cryptographic public/private key pair used to strong name the assembly, “b77a5c561934e089″ in case of “System.Data.dll”)
- Processor Architecture – Defines the assembly’s format, such as MSIL (intermediate language) or x86 (binary for Intel x86 processors)
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. (Note that in the real world, Spring.Core.dll is in fact released as strongly named by the good folks on the Spring.NET project; the screen shot below was done on a non-production version of that DLL.)
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).
Approach #4: (Bonus!) Viewing Strong Name with Windows Explorer
This post promised three ways to tell if a .NET Assembly has a strong name - but here is a bonus 4th way. 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. If you are examining the GAC, this can be handy.
Of course, if an assembly is in the GAC at all, it is strongly named by definition; assemblies are required by .NET to be strongly named to be allowed in the GAC.
Strong Naming for Silverlight
Silverlight also has support for strongly named assemblies, which is needed for the Cached Assembly Feature introduced in Silverlight 3.0.
(Silverlight 4 also introduces supports for digital signatures on XAP files, created by signtool.exe, which are validated by the Silverlight runtime for out-of-browser (OOB) applications running with elevated trust.)
Strongly Name Assembly != Digitally Signed Assembly
Strong Names and Digital Signatures are Orthogonal Concerns - Almost
Strongly Naming and Digitally Signing are largely orthogonal concerns. They have different purposes, different tools, and the digital certificates may come from different sources (for publicly distributed binaries, the certs for Digital Signing usually will come from a PKI source, though that is not essential for the Strong Naming certs).
The only dependency among them is that if the Assembly is to be Strongly Named, then the Strong Naming step has to happen before the Digital Signing step.
How do I check whether an assembly is Digitally Signed? You can run the following command to determine whether assembly “foo.dll” is digitally signed:
signtool verify /pa foo.dll
If you want to see the hash – for example, to compare with another assembly’s hash – then you can view it using the following command sequence:
signtool verify /v /pa /ph foo.dll | find "Hash"
Of course, you can use sn.exe and signtool.exe together (one after another) to examine an assembly to ascertain both whether it is strongly named and whether it has been digitally signed.
Strong Names are 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 (which is deliberate). While a strong name may help alert you to tampering, realize that 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. One source of digital certificates that can be used for Digitally Signing assemblies is Verisign which has Authenticode Certificates.
See also the response to this comment for more details.
March 14, 2010 at 6:09 am
You cannot believe how long ive been googling for something like this. Through 10 pages of Yahoo results and couldnt find anything. Quick search on bing. There was this…. Really have to start using it more often!
January 1, 2011 at 7:57 pm
Hi Bill Wilder,
Thanks for the nice article. I too have been googling for something like this . Though I have still some queries around the difference between strong name and digital signing (i.e. diff between signtool and sn). When you say , orthogonal , can you explain with an example.
When we strong name an assembly, we use a key to give it a strong name. Is it not enough for protecting the integrity and verification. Doesn’t strong name produce a digital signature in an assembly manifest?. Why do we need additional digital signing?. Is it like , first we give strong name using our key and then digital sign it with the certificate using signtool?. I think I am missing something in my analysis. Please help.
January 4, 2011 at 8:54 pm
@sveerap – thanks for the feedback. My point “Strong Names and Digital Signatures are Orthogonal Concerns” can be restated as they have nothing to do with each other. For example, you can have one with out the other, or you can use them both, but they don’t overlap.
It is unfortunate that applying a strong name and applying a digital signature both involve similar crypto concepts and both update the binary, but that happens to be the case. Also, I think it would have been possible for Microsoft to design an approach that only required one step, but this would have been at the expense of complexity for those who only wanted to strong name – this is because the digital certificates used for strong naming can be generated by you, on your personal dev machine, whereas the digital certificates used for digitally signing will typically be purchased from a PKI authority like Verisign (or perhaps provided from an internal PKI within your company for internal-use-only assemblies).
When you apply a strong name, sn.exe updates the assembly (e.g., Foo.dll) with an unambiguous entry claiming something like “this binary is named Foo.dll, is of version 1.2.3.4, is culture ‘en-us’ (or neutral, etc.), is for processor architecture MSIL (or x86, etc), and Public Key ‘abcde…’ was used to create the strong name.” This is to avoid the “DLL Hell” mentioned above within the post.
DLL Hell can happen any time you need to concurrently support more than one version of an Assembly (or DLL as we used to call them). With strong names, you can now have two Assemblies, both named Foo.dll, used concurrently on your system – they can even both be in the “same” place, side-by-side in the Global Assembly Cache (“GAC” – “the gack”). Further, your application can choose to only work with Foo.dll version 1.2.3.4 (because it was tested with that), and can fail fast (if you want it to) when Foo.dll 2.0.0.0 is installed and 1.2.3.4 is no longer available. Now further imagine you want a version of Foo.dll for French and another for Russian; no problem. Now you migrate Foo.dll from raw x86 over to MSIL architecture; no problem. DLL Hell is avoided and more fine-grained control is available.
Now so far this only addresses being clear about which version of the assembly ought to be loaded. And it is most of the way there. But is not entirely SECURE. It would be possible for a hacker to create a tampered assembly that appeared to be Foo.dll version 1.2.3.4 – but wasn’t. To ensure that the binary was not (maliciously or otherwise) edited after creation, we apply a digital signature to the whole file.
The only interdependency caveat is that you’ll need to apply the strong name before applying the digital signature. Both the strong name and the digital signature will change the binary, but due to the purpose of the digital signature, it comes afterwards since it is used to tell you that the assembly has not been tampered with since the strong name was applied.
In summary, the strong name and the digital signature address different architectural concerns. The strong name says says “this binary is named Foo.dll, has version 1.2.3.4, is culture ‘en-us’, and is for processor architecture MSIL” while the digital signature says “you can trust that these bits have not changed since the the strong name was applied.”
In particular, if you are developing assemblies exclusively for internal use within a company, and don’t need to worry about hackers or conflicts, you are probably fine with skipping the digital signing. But you definitely will want the strong name.
Hope that helps.
-Bill
May 17, 2011 at 7:53 pm
In the last sentence of the second-last paragraph I think you mean “you can trust that these bits have not changed since the the digital signature was applied.”
May 17, 2011 at 10:03 pm
@renniepet – you are indeed correct – that is what I meant. Unfortunately, WordPress does not appear to allow me to edit that comment (http://blog.codingoutloud.com/2010/03/13/three-ways-to-tell-whether-an-assembly-dl-is-strong-named/#comment-981) to correct it. Thank you for the clarification.
March 15, 2011 at 4:23 am
Hi,
This article is very useful! Thanks a lot!
I also have a question : I am trying to make my assembly strong named but I am having an error because another dll than I am using in the project is not strong named. How can I make it strong named? (the dll is from AutoCAD C:\Program Files\Autodesk\AutoCAD Architecture 2011\ acdbmgd.dll). Hope you can help me. Thanks in advance.
March 15, 2011 at 1:58 pm
@Ioana it appears you are aware that strong naming can only be applied to assemblies that rely only on other assemblies which are strong named. So I see you problem. I suppose you could use the “sn” tool (see http://msdn.microsoft.com/en-us/library/k5b5tt23.aspx) to strong name the AutoCAD file and “see what happens” and whether it meets your needs. Make backups first..
Of course, you may not yet know the state of the OTHER assemblies the AutoCAD dll relies on, so you may need to recursively apply strong names.
August 2, 2011 at 7:07 pm
[...] use the Strong Name Tool (sn.exe) or the Microsoft Intermediate Language Disassembler (ILDASM.EXE). Here’s a blog that shows how to do either one. Or you can simply trust that it is strong named. If it isn’t, the next step won’t [...]