Location and management of the .snk file

Question

I am currently installing my .net libraries for signing using a strongly typed key. I use the .snk file to sign my dll based on each solution. Therefore, for each solution, it has its own .snk file. Is this a good practice? For example, I have a class library that outputs several different dlls from each of the projects within the solution, each of which is signed with the .snk key.

My question is about storing a key in source control. When I distribute my code for each version. If the key is:

a. Exist outside the branches and do not branch out - providing the same key for each branch B. Exist inside the branch, but the same for each branch C. Exist inside the branch and change D. for each branch. Other (please specify)

Suggestions please?

It is also best to sign the dll by putting the following in the SolutionInfo file: is there an alternative?

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

Answer 1

Depending on your particular implementation, it is usually best to store the .snk key file in the branch you are working on.

Use case: we change the assembly signing key between versions v1.0 and v2.0. You still want to maintain the current code in the trunk, developing against the correct key in your branch.

Secondly, (and this is only best practice, not required depending on your situation - for example, how well you trust other developers) .snk file that you keep in the initial control should contain only the public key, and the solution should be configured only for a delay.

This prevents the distribution of your private key, which should be stored on the build server (most likely in the Windows key manager) and used during release builds to fully sign assemblies. If you do not have a build server, it is best to have 1 or 2 people who are entrusted with the private key, after which they can sign assemblies using sn.exe after the build. A simple shell script or batch file can automate this process.

Finally, and only if you decide to hold the sign, you need to add an entry to the .NET assembly validation list ( sn.exe -Vr *,<publicKeyToken> ) on all development workstations that will start / debug assemblies with a delayed subscription. Depending on the target platform, you must run this on both the 32-bit and 64-bit versions of the VS command line.

Hope this helps.

Answer 2

There are two main strategies. The first is suitable for very large companies, which should be afraid that someone else will replace their assemblies for malicious purposes. Such as Microsoft, Adobe or Oracle. No one, except a small set of trusted civil engineers, has access to the key, the code is designed and tested using a delayed signature.

Another for everyone else, you just sign the assembly to get it in the GAC, or because you send it to the second side, which might want to put it in the GAC. The actual key that you use does not matter, and you should not put it in a large safe. Just use Project + Properties, Signing tab. Create a key and test it with the project.