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