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