.net – Best practices for signing assemblies with multiple projects and developers

assembly-signingnetvisual studio

I’m looking for recommendations and best practices for applying signed assemblies in an organization with 30+ developers, 20+ solutions and 60+ projects. We’re using Visual Studio Team System 2008 and TFS.

While creating a key and signing the assembly is a very easy and straight forward procedure, I’m concerned how we manage this the best way.

My thoughts so far:

Each solution, which typically has between 3 and 20 projects, will have a single .pfx key file placed in the solution root folder.
Each solution will have a unique strong password for the key.

Will we encounter any problems with that approach?

Some other ideas:

Use the same key file for all projects across solutions. Will this make stuff easier for us? Is it a bad idea? Is it even possible?
Should each project have its own unique key? Why, why not?

Any input, good/bad experiences and recommendations are welcomed. 🙂

Best Answer

In the past, I've used a single key for multiple solutions and projects very effectively. Its a simple approach that ensures that only people with access to the private key file can publish a build that passes the strong name check.

Note: To use the single key file, we found it easiest to add the file as a link to each project.

The one disadvantage I see is that having the key file available to your developers means its not quite as private as it should be. Ideally, as few people as possible (eg just the build process) should have access / know the password.

The single file approach keeps the management of the keys simple (there's only one) while still allowing for the benefits of strong naming.

Related Solutions

C# – Best practices for catching and re-throwing .NET exceptions

The way to preserve the stack trace is through the use of the throw; This is valid as well

try {
  // something that bombs here
} catch (Exception ex)
{
    throw;
}

throw ex; is basically like throwing an exception from that point, so the stack trace would only go to where you are issuing the throw ex; statement.

Mike is also correct, assuming the exception allows you to pass an exception (which is recommended).

Karl Seguin has a great write up on exception handling in his foundations of programming e-book as well, which is a great read.

Edit: Working link to Foundations of Programming pdf. Just search the text for "exception".

.net – 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.

Best Answer

Related Solutions

C# – Best practices for catching and re-throwing .NET exceptions

.net – Best practices for signing .NET assemblies

Related Topic