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:
Will we encounter any problems with that approach?
Some other ideas:
Any input, good/bad experiences and recommendations are welcomed. :)
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.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With