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

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.