.snk文件的位置和管理

Question

我目前正在设置我的.net库，使用强类型密钥进行签名。我使用.snk文件对每个解决方案中的dll进行签名。所以每个解决方案都有自己的.snk文件，这样做是否正确？例如，我有一个类库，从解决方案中的每个项目输出多个不同的dll，每个dll都使用.snk密钥进行签名。

我的问题是关于密钥在源代码控制中的存储。由于每次发布时我都会分支我的代码，那么密钥应该：

A. 存在于分支之外且不被分支化 - 确保每个分支都使用相同的密钥 B. 存在于分支之内但每个分支都相同 C. 存在于分支之内且对于每个分支都不同 D. 其他（请指定）

请给出建议。

另外，最佳实践是通过将以下内容放置在SolutionInfo文件中来签署dll，还是存在其他替代方法？

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

- amateur

Answer 1

有两种基本策略。第一种适用于需要担心其他人替代其程序集进行恶意用途的非常大的公司，例如微软、Adobe或Oracle。只有一小部分可信任的构建工程师可以访问密钥，代码是通过延迟签名开发和测试的。

另一种策略适用于其他所有人，您只需签署程序集即可将其放入GAC中，或者因为您将其发送给第二方，该方可能想将其放入GAC中。您使用的实际密钥并不重要，也不必将其放在大保险库中。只需使用“项目+属性”、“签名”选项卡生成密钥，并将其与项目一起检查即可。

- Hans Passant

Answer 2

根据您的具体实现，通常最佳实践是将.snk密钥文件保留在您正在工作的分支中。

应用场景是：我们在v1.0和v2.0之间更改程序集签名密钥。您仍然希望能够在主干线上维护当前代码，同时在您的分支中使用正确的密钥进行开发。

其次（这只是最佳实践，根据您的情况不一定需要-例如您对其他开发人员有多大信任），您在源代码控制中保留的.snk文件应仅包含公钥，并且解决方案应配置为仅延迟签名。

这可以防止传播您的私钥，私钥应存储在构建服务器上受保护的位置（很可能在Windows密钥管理器中）并在“发布”构建期间用于完全签署程序集。如果您没有构建服务器，则最佳实践是委托1或2个人负责私钥，然后他们可以在构建后使用sn.exe签署程序集。一个简单的shell脚本或批处理文件可以自动化此过程。

最后，仅当您选择延迟签名时，您需要在所有运行/调试延迟签名程序集的开发人员工作站上添加.NET程序集验证列表条目（sn.exe -Vr *,<publicKeyToken>）。根据平台目标，您需要在VS命令提示符的32位和64位版本中运行该命令。

希望这有所帮助。

- lukiffer