我做了以下经验：
现在，在 (1) 中，我假设这是正确的行为，因为来自两个文件的签名应该相同，为空，但在情况 (2) 中，公共令牌应该相同，但签名应该不同，在控制台应用程序中签名应该被填充并且在dll中为空，因此控制台应用程序应该无法调用dll。
这让我相信强名称验证只使用公钥令牌，这是真的吗？
【问题讨论】：
标签： c# security code-signing strongname
如果使用相同的公钥，延迟且完全签名的程序集的强名称是相同的。
这就是为什么您不需要在完全签署 dll 后修改（通过重建）exe 中的引用。
然而，延迟签名的程序集将不包含证明它是用私钥签名的签名（有一个很好的理由：它没有用私钥签名）。
此签名不是全名的一部分，因此程序集仍将与完全签名的程序集的全名匹配。
默认行为是拒绝加载延迟签名的程序集。不是因为它的全名不匹配，而是因为程序集未通过签名验证。
如果您使用 sn.exe 关闭签名验证，则将接受 dll 强名称，而不检查匹配的签名。无论调用 dll 的 exe 是否完全签名，都会出现这种情况。
如果您没有使用 sn.exe 关闭验证，我预计该 exe 根本不会运行。
如果您使用 sn.exe 关闭了使用公钥对所有程序集的验证，我希望 exe 可以正常运行并调用 dll。这是通过使用：
sn.exe -Vr *,<publicKeyToken>
如果您使用 sn.exe 仅关闭 exe 的验证，同时保持 dll 的验证处于活动状态，我希望 exe 可以运行，但在尝试调用 dll 时会失败。这是使用：
sn.exe -Vr <dllAssemblyName>,<publicKeyToken>
为确保不跳过程序集验证，请使用：
sn.exe -Vx
或使用
sn.exe -Vu <dllAssemblyName>,<publicKeyToken>
使用与 -Vr 相同的语法选择性地打开验证。
有 32 位和 64 位的 sn.exe。它们分别影响 32 位和 64 位进程。我建议始终在两者中运行 sn.exe 命令以避免意外。
【讨论】：