Agile.NET启用强名称后出现引用解析失败，常见报错要么发生在编译期，提示引用无法解析或找不到程序集，要么发生在运行期，提示清单定义不匹配。多数问题并非加密混淆本身，而是程序集身份发生了变化，或运行时加载到的并不是你期望的那份DLL，导致版本号与PublicKeyToken对不上。

　　一、Agile.NET强名称启用后引用解析失败有哪些常见诱因

　　启用强名称会把程序集身份从弱名变成强名，引用方在绑定时会更严格，一旦身份或加载路径出现偏差，就会直接失败。

　　1、签名密钥变化导致PublicKeyToken变化

　　同一个程序集如果用不同snk重新签名，PublicKeyToken会变化，引用方仍按旧Token绑定，运行期就会出现清单不匹配或直接找不到程序集。

　　2、原来未签名后来改为签名但引用方未重编译

　　引用方编译时记录的是旧身份信息，后来目标程序集被签名，身份字段补齐，引用方不重编译就容易出现绑定不一致。

　　3、AssemblyVersion被改动或被工具重写

　　强名称绑定对版本号更敏感，如果Agile.NET输出物把AssemblyVersion改了，或你同时在代码里改版本又在工具里改版本，引用解析会在版本校验阶段失败。

　　4、同名不同版本DLL同时存在导致加载到错误副本

　　解决方案目录、输出目录、插件目录、安装目录里若同时存在多份同名DLL，运行时很可能加载到旧副本或未签名副本，看起来像签名启用后就坏了，实际是加载路径被污染。

　　5、GAC与私有目录混用造成优先级反转

　　如果某个版本被装入GAC，而应用目录又放了另一个版本，绑定顺序与期望不一致时会出现只在某些机器报错的现象。

　　6、友元程序集与内部可见性未同步更新

　　若程序集使用InternalsVisibleTo并带有PublicKey信息，强名称变更后友元声明仍指向旧Key，会出现编译或运行期的访问异常，常被误认为引用解析失败。

　　二、Agile.NET强名称与引用版本对齐应怎样处理

　　处理原则是先把程序集身份稳定下来，再让所有引用方统一对齐到同一份身份与同一份物理文件，最后才谈版本演进与发布节奏。

　　1、优先确保签名密钥保持一致以稳定程序集身份

　　如果该程序集过去已经签名，Agile.NET里必须选择同一份snk重新签名，避免PublicKeyToken变化；如果过去未签名，先确定一份长期使用的snk作为唯一来源，后续不要随意更换。

　　2、把签名位置前移到编译阶段减少对齐成本

　　在Visual Studio中打开【项目】→【属性】→【Signing】勾选【Sign the assembly】，选择固定snk后先正常编译一次，让引用方在编译期就绑定到强名身份；再把编译产物交给Agile.NET做保护并保持重新签名使用同一snk。

　　3、统一控制AssemblyVersion，避免工具与代码双边改写

　　在工程侧明确AssemblyVersion的管理方式，例如只通过版本文件或构建流水线生成；在Agile.NET侧关闭会改写版本的选项，或明确规定仅允许变更FileVersion不动AssemblyVersion，保证绑定版本稳定。

　　4、让引用方重新引用并重编译，清理旧身份残留

　　对引用该DLL的所有工程执行一次干净对齐，先移除旧引用，再重新添加指向最新输出DLL的引用，然后执行【Build】→【Clean Solution】与【Rebuild Solution】；若使用包分发，先更新包版本再恢复依赖，避免引用仍指向旧缓存。

　　5、处理引用属性避免被Specific Version锁死

　　在引用属性中检查Specific Version是否被设为True，若是，改为False或改成与当前版本完全一致；同时确认Copy Local为True或按部署模式明确放置路径，避免运行期仍从旧目录取DLL。

　　6、对运行期版本漂移用绑定重定向兜底但不替代签名一致性

　　对仅版本号变化导致的绑定失败，可在应用配置中加入bindingRedirect把旧版本重定向到新版本；但如果PublicKeyToken变化，重定向无法解决，必须回到同Key签名或更新引用方身份。

　　三、Agile.NET加载路径核验与清理重编译

　　当你已经确认签名与版本策略没问题，但仍然偶发失败，下一步应把绑定过程证据化，找出到底加载了哪一份DLL，再把路径污染清干净。

　　1、用绑定日志定位实际加载的程序集路径

　　在.NET Framework环境可使用名为fuslogvw的绑定日志工具开启记录，复现一次失败后查看日志，确认加载的物理路径与期望路径是否一致，很多问题会直接暴露为加载到了旧副本。

　　2、对输出目录做一次全量清理避免旧副本残留

　　关闭IDE后删除解决方案下所有bin与obj目录，再删除应用部署目录中同名DLL的旧版本，只保留本次构建输出；随后重新打开解决方案执行全量重建，确保没有任何历史产物参与运行。

　　3、检查Agile.NET输出命名与输出目录是否与引用一致

　　在Agile.NET里核对输出文件名是否保持原程序集名不变，输出目录是否与IDE或发布脚本一致；避免出现编译期引用的是A目录，运行期实际复制的是B目录的情况。

　　4、核对插件式加载与反射加载的路径规则

　　若应用通过插件目录或反射加载程序集，需确认加载代码指向的目录已同步更新到强名版本，并且目录中只存在唯一版本；反射加载不会自动跟随项目引用更新，这是强名称启用后最容易被忽略的点。

　　5、把对齐动作固化到发布流程里避免回归

　　在CI中增加校验步骤，发布前对目标目录扫描同名DLL是否存在多份版本，并记录每个DLL的版本号与PublicKeyToken；一旦发现重复或Token不一致直接阻断发布，避免问题进入现场环境后才暴露。

　　总结

　　Agile.NET启用强名称后引用解析失败，最常见根因是PublicKeyToken变化、AssemblyVersion漂移、以及同名DLL多副本导致加载路径跑偏。优先用同一snk稳定程序集身份，把签名前移到编译阶段并统一版本管理，再让所有引用方移除旧引用后重建对齐；若仍失败，就用绑定日志确认实际加载路径并彻底清理旧产物，把对齐与校验写进发布流程，问题通常能稳定消除。