location of .snk file and management of it

Question

I am currently setting up my .net libraries to be signed with a strongly typed key. I am using .snk file to sign my dll's on a per solution basis. So for each solution, it has its own .snk file. Is this correct practice? For example I have a class library that outputs several different dll's from each of the projects within the solution, each are signed with the .snk key.

My question surrounds the storage of the Key in source control. As I branch my code for each release. Should the key:

A. Exist outside the branches and not be branched - ensuring its the same key for each branch B. Exist within the branch but be the same for each branch C. Exist within the branch and change for each branch D. Other (please specify)

Suggestions please?

Also is it best practices to sign the dll's by placing the following in the SolutionInfo file or is there any alternative?

[assembly: AssemblyKeyFile("<<absolute path>>\\MyKey.snk")]

Answer 1

Depending on your specific implementation, it's typically best practice to keep the .snk key file in the branch you're working on.

The use case being: we're changing our assembly signing key between v1.0 and v2.0. You would still want to be able to maintain current code in the trunk, while developing against the correct key in your branch(es).

Secondly, (and this is only a best practice, not necessary depending on your situation - e.g. how well do you trust the other developers) the .snk file you keep in source control should only contain a public key, and the solution should be configured to delay sign only.

This prevents dissemination of your private key, which should be stored protected on the build server (most likely in the windows key manager) and used during "release" builds to fully sign the assemblies. If you don't have a build server, it's best practice to have 1 or 2 people entrusted with the private key at which point they can sign the assemblies with sn.exe after the build. A simple shell script or batch file can automate this process.

Lastly, and only if you choose to delay sign, you'll need to add an entry to the .NET assembly verification list (sn.exe -Vr *,<publicKeyToken>) on all the developer workstations that will run/debug the delay signed assemblies. Depending on the platform target you'll need to run that in both the 32- and 64-bit versions of the VS command prompt.

Hope that helps.

Answer 2

There are two basic strategies. The first one is suitable for very large companies that need to fear somebody else substituting their assemblies for malicious purposes. The likes of Microsoft, Adobe or Oracle. Nobody but a small set of trusted build engineers have access to the key, the code is developed and tested by delay signing.

The other is for everybody else, you just sign the assembly to get it into the GAC or because you ship it to a 2nd party that might want to put it in the GAC. The actual key you use doesn't matter nor do you have to put it in a big vault. Just use Project + Properties, Signing tab. Generate a key and check it in along with the project.