Best practices for signing assemblies with multiple projects and developers

Question

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. :)

Answer 1

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.

Answer 2

We currently use the same strong key (.SNK) for every project in our solution. Depending on your project is how you manage to different keys for every project.

If you want higher security I suppose you could recreate the key for every project, but it's going to be a nightmare to manage. Remember that at the end of the day, the SNK just shows that the code comes from your company, and prevents the assemblies from being altered, it's not a huge in-house security feature.

For that, you should limit your source control and look at using a build server etc. if you don't trust/don't want the developers to build code.

Answer 3

You can also keep the strong name key in a folder at root level, on same level as all project folders. When you choose this file in project properties -> signing tab, the key file gets copied to the project folder. Delete this file. Open the .csproj file in notepad. Look for the following tag mykey.snk Manually edit the path of key file, make sure you specify a relative path from project folder. Save the file. Now open the project properties in visual studio. You can see the path updated to point to the correct location.