Best practices for signing assemblies with multiple projects and developers
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
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.