Best practices for signing .NET assemblies?

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.

Leave a Comment