Question

My application consists of three assemblies: a single EXE which references a couple of DLLs. The DLLs are private to my application – they are used only by this executable.

Should these assemblies be given a strong name?

FxCop suggests that they should – for all of the assemblies it currently produces:

CA2210: Sign <assembly> with a strong name key.

However, this advice says:

In general, you should avoid strong-naming application EXE assemblies.

and

you may want to avoid strong-naming components that are private to your application.

Should I give these assemblies a strong name? What are the benefits of doing so (or not doing so) in this case?

Edit:

Looking at several applications with a similar structure, there seems to be no consensus on this issue. The binaries of Paint.NET and Crack.NET are not strong-named, whereas those of .NET Reflector and Snoop are.

Interestingly, with the Expression suite Microsoft have taken the latter approach: in Expression Blend, for example, they have chosen to strong-name sign both Blend.exe and the accompanying DLLs (such as Microsoft.Expression.Blend.dll).

It seems that I am unlikely to receive a simple answer to my first question: “Should I give these assemblies a strong name?”. However, my second question still stands:

Are there any benefits to strong-name signing binaries in this situation? Or, are there any benefits to not doing so?

Edit 2:

If there are no overwhelming reasons to go either way, I am inclined towards giving my assemblies a strong name. I’d thus be interested in whether anyone can expand upon this (from the first link):

“strong-naming can make it more difficult to manage dependencies and add unnecessary overhead for private components.”

Answer 1

As I see it, these are the benefits to strong-name signing in this situation:

• Prevents an attacker replacing a DLL with one signed using another key (or not signed at all), without also replacing the EXE (since the EXE contains a reference which includes the public key).
• Prevents an attacker modifying an assembly while retaining the existing key (since this will cause signature verification to fail). Note, however, that as of .NET 3.5 SP1, signature verification in this situation is disabled by default.
• Could prevent the application from running with mismatched versions of assemblies – if a DLL has been incorrectly replaced due to a deployment error, the application will fail to load it rather than trying to use a (potentially incompatible) wrong version.
• Avoids FxCop warnings.

And the drawbacks to signing (I believe these are what the linked article is referring to):

• Replacing a DLL with a compatible newer version (in order to fix a bug, for example) requires replacing the EXE.
• In .NET versions < 3.5 SP1, strong-named assemblies take longer to load due to signature verification.
• Strong-named DLLs also take longer to load because the loader performs a (futile in this situation) search of the GAC before looking locally.

It does seem a shame that the choice is either strong-naming (and thus requiring references to match an exact key and an exact version), or not strong-naming (and not requiring either to match). If it were possible to require a key but not a particular version, perhaps it would be possible to get the first 2 benefits of signing without also getting the first drawback. Maybe this is possible by applying a strong name and then dealing with the versioning issue using app.config?