.NET: Should executables be strong-name signed? What about private DLLs?

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.

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?