程序经过Agile.NET保护后，可能正常启动，却在加载插件、打开报表或反序列化数据时出错。这些功能常常依赖类型名称、方法名称或程序集信息。排除规则需要对应到具体调用对象，同时还要检查程序集合并、运行库部署等设置，才能判断异常出在哪一环。

　　一、Agile.NET怎么排除指定类型和方法

　　设置前先确认需要保留什么：是类名、某个方法名，还是整个类型及其成员。范围不同，配置方式也有区别。

　　1、从重命名页面添加排除对象

　　①打开保护工程，进入【Renaming】，确认当前勾选的是需要处理的程序集。

　　②点击【I want to specifically exclude members from the obfuscation】，在排除设置中定位目标类型或成员，并保存工程。

　　③重新生成保护文件，用程序集查看工具检查目标名称是否保留，再执行对应功能。

　　定位时应核对命名空间和方法参数。同名类型可能分布在不同程序集，重载方法也可能只有一个被第三方组件调用，不能只凭短名称判断。

　　2、在源码中声明排除范围

　　有源码时，可以使用System.Reflection.ObfuscationAttribute，让规则跟随代码保存。

　　①需要保留整个类型及其成员时，在类型声明上添加该特性，明确设置Exclude=true、ApplyToMembers=true。

　　②只需保留类型名称时，将ApplyToMembers设为false；仍需保留的方法再单独添加排除特性。

　　③只排除某个方法时，将特性加在对应的方法声明上。修改后重新编译，再让保护工程读取新程序集。

　　方法上的独立声明优先于类型传递下来的设置。例如，类已经排除，但其中某个方法声明了Exclude=false，该方法仍可能被处理，需要一起核对。

　　3、确认排除解决的是哪类问题

　　保留名称不等于撤销全部保护。第三方组件通过字符串查找方法时，重命名排除通常有帮助；异常若与运行时代码执行或程序集合并有关，还要检查对应保护项。

　　①先用仅启用重命名的配置验证排除效果。

　　②确认功能恢复后，逐项恢复其他保护，每次使用新的输出目录测试。

　　③若异常再次出现，记录刚恢复的选项，围绕该项继续缩小范围。

　　二、Agile.NET保护后第三方组件兼容性异常如何核验

　　排查时保留一份未经保护的发布目录。同一台机器、同一组输入、同一个操作入口，才能比较保护前后的差异。

　　1、检查组件如何找到业务类型

　　①记录首次异常的完整信息，包括内部异常、类型名、方法名和调用堆栈。

　　②检查配置文件、插件注册信息，以及代码中的Type.GetType、GetMethod等调用，确认是否使用固定名称寻找对象。

　　③将这些名称与保护后的程序集逐一对照，补充实际被查找对象的排除规则，再运行原来的失败操作。

　　例如，报表插件按配置中的类名创建数据提供器，保留报表窗口本身并不能解决问题，需要保留配置真正指向的类型。数据字段丢失时，还应查看序列化是否依赖属性名称。

　　2、分别验证外部调用和程序集合并

　　第三方DLL没有被保护，也不代表调用它的路径没有变化。【Method Call Obfuscation】会处理调用方程序集中的外部成员调用；合并程序集则会改变文件组织方式。

　　①在工程副本中，取消调用方程序集的【Method Call Obfuscation】选项，保持其他设置不变，重测失败功能。

　　②如果启用了程序集合并，再单独取消可疑组件的合并设置，按原有文件结构部署测试。

　　③比较两次结果，分别记录异常是否消失，避免同时修改后无法判断原因。

　　合并发生在其他保护操作之前，次要程序集原先单独设置的保护选项会被忽略，合并结果采用主程序集的设置。因此，不能仅凭某个DLL页面上未勾选保护，就认定合并后仍保持原状。

　　3、核对实际加载的文件和运行环境

　　①在调试器中查看实际加载的组件路径、版本和进程位数，确认没有读到旧目录中的DLL。

　　②若使用代码加密，检查【Disable runtime embedding】是否启用；选择分离部署时，将生成的运行库组件一并放入发布包。

　　③在干净目录中部署完整文件，重复加载组件、创建对象和执行首次业务调用的过程。

　　加载失败、格式错误和方法找不到，应分别沿依赖路径、位数、版本及名称继续核查。仅看到第三方组件出现在堆栈中，还不足以判断组件本身不兼容。

　　三、Agile.NET排除规则如何验证和留存

　　故障消失后，还需要确认规则是否覆盖了实际使用场景。插件能加载，并不意味着它的所有反射入口都已经通过验证。

　　1、补测延迟执行的功能

　　①按实际使用顺序测试插件初始化、页面打开、数据读取和结果导出。

　　②对涉及反射或序列化的功能，补测不同对象类型、空数据和历史数据。

　　③将临时放开的整个程序集逐步缩小到类型或方法范围，每缩小一次就重跑相关用例。

　　2、把日志对应到本次保护产物

　　①保存保护工程、输入程序集版本和本次生成的名称映射文件。

　　②需要还原堆栈时，打开主功能区的【decode stack trace】，选择对应映射文件，粘贴异常堆栈后执行【decode】。

　　③将还原后的调用位置与失败步骤一起存档，避免下次拿其他构建的映射文件分析。

　　排障阶段可采用【Printable Chars】重命名方案，便于利用错误报告还原调用信息。

　　总结

　　项目后续接入新的报表、插件或数据交换组件时，可以把它们依赖的类型、方法和配置名称写进接口记录，并安排一次保护后的发布验证。这样，维护人员接手时能直接找到保留名称的原因，也方便在组件升级后判断原有规则是否还适用。希望这些操作能帮助大家更快定位具体调用环节，减少反复试改。如果有Agile.NET排除规则配置、第三方组件兼容性核验等方面的需求，欢迎联系咨询。