据我了解，强命名会创建一个程序集的加密哈希，该程序集用作加载 dll 的强名称。
我希望使用此功能来检测二进制文件的损坏，以通知用户该软件存在问题，他们需要重新安装它。
这适用于对二进制文件的一些更改，但是我发现修改二进制文件，尤其是二进制文件中的静态字符串，不会导致应用程序报告它无法找到适当强名称的 dll。
谁能向我解释一下程序集中的哪些数据用于创建强名称，以及为什么强命名并不总能检测到 dll 的修改？有没有办法强制它在强命名中包含附加信息？
有没有另一种方法可以检测二进制文件的损坏？
干杯
瑞安
你应该看看这里：Authenticode Signatures and Strong Name Signatures和How do I Sign .Net assembly with Authenticode signature？
这两个签名完全相互独立。强名称有助于为程序集提供唯一标识。Authenticode 允许您验证程序集的作者是谁。
和
如果将这两种类型的签名都应用于程序集，则强名称签名将包含在 Authenticode 签名中。这意味着我可以修改 Authenticode 签名的字节，使其不再有效，而不会使强名称签名无效。反之则不然——修改强名称签名的字节会使它和 Authenticode 签名无效。
据我所知，强命名中使用的散列包括整个文件，所以我不确定为什么某些更改不会触发验证。
您的程序集是否有可能添加到跳过验证列表中？
强命名程序集时创建的数字签名对程序集的内容进行哈希处理，但任何 Authenticode 签名、程序集的强名称数据和 PE 标头校验和除外，然后使用私钥对哈希进行签名。
也许它是您正在更改的排除项目之一，在这种情况下，强名称仍将正确验证，并且程序集仍将正常加载。
根据定义，强名称由四个属性组成：文件名（减去扩展名）、版本号、文化标识和公钥标记（公钥的散列）。无法在强命名约定中包含其他信息。
我检测到了同样的行为。我对程序集进行了强命名，然后使用十六进制编辑器修改了一些静态字符串。令人惊讶的是，加载程序集的可执行文件没有抛出任何异常，而是加载了更改后的库。在 Microsoft 文档中进行了一些搜索后，我发现了一个对我有帮助的提示。
据说有一种旁路机制可以在某些条件为真时更快地加载程序集。
要禁用此绕过，您已在 app.config 中放置了一个标志。
<runtime>
<bypassTrustedAppStrongNames enabled="false" />
</runtime>
之后，当程序集被修改时，可执行文件会引发异常。
