Dapper.StrongName 升级后报强名称签名验证失败

把 Dapper.StrongName 升级到 2.1.86 后，.NET Framework4.8 应用启动或首次加载程序集时报 Strong name signature could not be verified，HRESULT 为 0x80131045。SQL 还没有执行，应先检查包和实际 DLL，而不是修改连接串或数据库权限。

该版本的发布构建误用了 public signing。它保留强名称身份相关信息，却不等于用私钥完成了目标运行时要求的完整签名。不能把异常中的“may have been tampered with”直接写成已经发现篡改；构建签名方式本身就能造成同样的加载失败。

正式 2.1.89 已经修正完整签名

NuGet 中的 Dapper.StrongName 2.1.89 已正式提供，发行记录明确修正各平台构建的完整签名。使用这个包的项目，可以按原有包管理方式更新，例如非集中版本管理项目的引用：

<PackageReference Include="Dapper.StrongName" Version="2.1.89" />

集中管理版本的项目应修改既有版本入口，不再增加另一份竞争声明。保留原锁文件与发布产物，通过原流程恢复、构建并生成新的完整部署包；只修改项目文件，却让服务器继续加载 2.1.86 的 DLL，不会恢复。

不要用关闭强名称验证、登记跳过验证或忽略程序集加载错误来上线。也不要把目标切换到另一个.NET 运行时，只为了绕过现有平台的加载要求。

核对真正被加载的文件

检查部署目录和实际依赖解析结果，确认没有旧 DLL 通过发布缓存、插件目录或历史绑定配置继续进入进程。程序集版本、包版本和文件来源可能不是同一个显示字段，不能只看某一处数字便认定部署已经更新。

若已有绑定重定向，按目标程序集的真实身份和项目要求检查，不要从 NuGet 包版本机械生成绑定版本号。换用非 StrongName 包还可能影响已有引用身份，并非一个可以不核对依赖图的等价替换。

暂时不能采用新包时，只能评估恢复此前保存、确认兼容的完整依赖和部署组合；不要从不明网站单独下载 DLL 覆盖。回退同样需要确认其他项目没有依赖新版本行为，并保留可复现的包来源。

验收从加载走到原查询

先在与生产相同的.NET Framework 环境核对应用能够加载正确程序集，再执行原有受控业务检查，确认依赖解析、查询映射和异常处理正常。现代.NET 上的一次加载成功，不能替代.NET Framework 的签名加载条件。

如果错误变成列映射 InvalidCastException，说明进入了另一层，需按真实列类型检查。保留旧发布包、配置和新包来源记录，撤回时恢复完整产物；修复签名只解决加载问题，不证明其他 Dapper 版本变化都已验收。