Best practices for signing .NET assemblies?

Question

I have a solution consisting of five projects, each of which compile to separate assemblies. Right now I'm code-signing them, but I'm pretty sure I'm doing it wrong. What's the best practice here?

• Sign each with a different key; make sure the passwords are different
• Sign each with a different key; use the same password if you want
• Sign each with the same key
• Something else entirely

Basically I'm not quite sure what "signing" does to them, or what the best practices are here, so a more generally discussion would be good. All I really know is that FxCop yelled at me, and it was easy to fix by clicking the "Sign this assembly" checkbox and generating a .pfx file using Visual Studio (2008).

Answer 1

If your only objective is to stop FxCop from yelling at you, then you have found the best practice.

The best practice for signing your assemblies is something that is completely dependent on your objectives and needs. We would need more information like your intended deployment:

• For personal use
• For use on corporate network PC's as a client application
• Running on a web server
• Running in SQL Server
• Downloaded over the internet
• Sold on a CD in shrink wrap
• Uploaded straight into a cybernetic brain
• Etc.

Generally you use code signing to verify that the Assemblies came from a specific trusted source and have not been modified. So each with the same key is fine. Now how that trust and identity is determined is another story.

UPDATE: How this benefits your end users when you are deploying over the web is if you have obtained a software signing certificate from a certificate authority. Then when they download your assemblies they can verify they came from Domenic's Software Emporium, and they haven't been modified or corrupted along the way. You will also want to sign the installer when it is downloaded. This prevents the warning that some browsers display that it has been obtained from an unknown source.

Note, you will pay for a software signing certificate. What you get is the certificate authority become the trusted 3rd party who verifies you are who you say you are. This works because of a web of trust that traces its way back to a root certificate that is installed in their operating system. There are a few certificate authorities to choose from, but you will want to make sure they are supported by the root certificates on the target operating system.

Answer 2

The most obvious difference between signed and unsigned assemblies is in a ClickOnce application. If you don't sign it, then users will get a scary "Unknown Publisher" warning dialog the first time they run your application. If you've signed it with a certificate from a trusted authority, then they see a dialog that's less scary. As far as I know, signing with a certificate you generate yourself doesn't affect the "Unknown Publisher" warning. Instant SSL from Comodo has examples of the dialogs.

There are some subtler differences. You have to sign an assembly before it can be installed in the global assembly cache (GAC) where it can be shared by multiple applications. Signing is integral to code access security (CAS), but I haven't found anyone who could get CAS working. I'm pretty sure that both the GAC and CAS work fine with certificates you generate yourself.