我目前正在设置我的.net库，使用强类型键进行签名。我正在使用.snk文件在每个解决方案的基础上签署我的dll。因此，对于每个解决方案，它都有自己的.snk文件。这是正确的做法吗？例如，我有一个类库，它从解决方案中的每个项目输出几个不同的dll，每个都用.snk键签名。
我的问题围绕着源控件中密钥的存储。当我为每个版本分支我的代码时。应该关键：
一个。存在于分支外部而不是分支 - 确保每个分支的密钥相同 B.存在于分支内，但每个分支都相同 C.存在于分支内并为每个分支进行更改 D.其他（请注明）
建议吗？
最佳做法是通过将以下内容放在SolutionInfo文件中来签署dll，还是有其他选择？
[assembly: AssemblyKeyFile("<<absolute path>>\\MyKey.snk")]
答案 0 :(得分：3)
根据您的具体实现，通常最好将.snk密钥文件保存在您正在处理的分支中。
用例是：我们正在更改v1.0和v2.0之间的程序集签名密钥。您仍然希望能够在主干中维护当前代码，同时针对分支中的正确密钥进行开发。
其次，（这只是一种最佳实践，根据您的具体情况不必要 - 例如，您对其他开发人员的信任程度如何）您在源代码管理中保留的.snk文件应该只包含一个公钥，以及解决方案应配置为仅延迟签名。
这可以防止传播您的私钥，该私钥应该在构建服务器上保存（最有可能在Windows密钥管理器中），并在“发布”版本中用于完全签署程序集。如果您没有构建服务器，最好让1或2个人委托使用私钥，此时他们可以在构建后使用sn.exe对程序集进行签名。一个简单的shell脚本或批处理文件可以自动执行此过程。
最后，只有当您选择延迟签名时，您才需要在将运行/调试延迟签名程序集的所有开发人员工作站上向.NET程序集验证列表（sn.exe -Vr *,<publicKeyToken>）添加一个条目。根据平台目标，您需要在32位和64位版本的VS命令提示符下运行该目标。
希望有所帮助。
答案 1 :(得分：3)
有两种基本策略。第一个适用于需要担心其他人将其程序集替换为恶意目的的大型公司。像微软，Adobe或甲骨文。除了一小组可信赖的构建工程师之外，没有人可以访问密钥，代码是通过延迟签名开发和测试的。
另一个是针对其他人的，您只需签署程序集即可将其发送到GAC，或者因为您将其发送给可能想要将其放入GAC的第二方。您使用的实际密钥无关紧要，也不必将其放入大型保险库中。只需使用Project + Properties，Signing选项卡。生成密钥并将其与项目一起检入。