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

Bustee

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.

Stays

Excellent, I think we'll try that. Can you explain how you add the file as a link? I don't think I'm familiar with that feature of VS. :) – Bustee

When you add, the button is split with an arrow on the right. Click on the arrow and you'll see "Add as Link" :) – Cypriot

Ah, of course. Thanks. :) But I think we'll have to copy the .pfx files to the individual solutions/project, because it's impossible to compile the project if the network is down and you access the file anymore. Eventually we'll replace the "common key" with a secret version during the build process on TFS. – Bustee

For VS2015, adding .pfx file as link and selecting it in "Signing" tab results in "Unable to get MD5 checksum from the key file. Could not find file" error messagebox. But, surprisingly, assembly seems to be strongly-signed after that, and builds and loads in other strongly-signed dlls normally. Still, it signifies that referencing keys as links is not a standard practice, so maybe it's better to stay with copying keys – Geralyngeraniaceous

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.

Cypriot

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.

Savaii