问题描述
这个问题是以下问题的延伸：
- Should each project being signed with a separate Strong Name Key (.snk)?
- snk vs. code signing certificate
- Any reason to ship .snk file with the project sources?
- https://docs.microsoft.com/en-us/dotnet/standard/assembly/enhanced-strong-naming
我正在研究自定义程序集的强命名及其代码签名，并阅读了各种 SO 帖子（见上文）和 MSDN。我了解以下内容：
- 强命名程序集无密码会创建一个 SNK 文件，并且仅标识程序集的发布者，以便可以将其部署到 GAC 并缓解所谓的
DLL Hell来自不同出版商的同名程序集。 - 强命名程序集使用密码向程序集添加代码签名并创建 PFX 文件，而不是 SNK 文件。这既可以识别发布者，又可以验证代码未被篡改。注意：此文件可以由受信任的证书颁发机构（如 Verisign 和 Digicert）创建并导入，也可以是在组织内创建的自签名证书。自创建 PFX 与创建强命名程序集的步骤相同，但您只需为其添加密码。
- 增强的强命名对我来说似乎有点神秘。它涉及创建一个强命名 SNK 文件（即没有密码），然后从中提取私钥。这似乎只是为了允许从已弃用的哈希算法迁移。
我理解 2 是 1 的逻辑扩展。我上面的理解正确吗？但是，上面的2和3有什么区别？ 3 是否比 1 有任何优势，或者它只是一种仅允许跨算法迁移的方法？换句话说，我认为 2 和 3 存在的原因不同；这是什么原因/实现？
解决方法
除 1 之外：您需要强命名以确保没有引用未签名的程序集。您可能不想使用 GAC。
更正2：代码签名！=强命名。强命名使用sn.exe 来创建一个键。对于代码签名，需要使用其私钥的 x.509 数字证书。证书本身没有密码。 PFX/PKCS#12 容器格式使用密码来保护私钥。其他选项。像例如可以使用智能卡或令牌。
所以 2 不是 1 的扩展。3 的优点是使用更好的哈希算法和两个而不是一个签名。