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