我做了以下经历：
现在，在（1）中我假设这是正确的行为，因为两个文件的签名应该是相同的，空的，但在情况（2）中，公共令牌应该是相同的，但签名应该是不同的，在控制台应用程序中，签名应该填充并且在dll中为空，因此控制台应用程序不应该能够调用dll。
这让我相信强名称验证只使用公钥令牌，这是真的吗？
答案 0 :(得分：2)
如果使用相同的公钥，则延迟和完全签名的程序集的强名称是相同的。
这就是为什么在完全签名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命令以避免意外。