程序直接调用的方法运行正常，通过配置文件指定类型、再用反射创建对象时却报错，这往往与名称变化有关。编译器可以识别的引用和运行时按字符串查找的名称，处理方式并不相同。Agile.NET能够自动识别部分需要保留的成员，但插件入口、动态拼接的类型名仍可能需要手动配置。下面采用官方文档中的英文界面名称，说明程序集规则设置和反射故障的检查方法。

　　一、Agile.NET如何配置程序集混淆规则

　　先确定哪些程序集参与处理，哪些名称必须供外部使用，再选择保护选项。首次配置适合分项验证，方便发现是哪一项改变了程序行为。

　　1、添加程序集并设置输出目录

　　①打开Agile.NET，点击【New】新建项目，再通过【Add...】添加主程序及相关DLL。

　　②设置独立的输出目录。默认输出位置通常是首个程序集所在目录下的Secured文件夹。

　　③程序集使用强名称签名时，选择对应密钥文件，供处理后重新签名。

　　④点击【Save】，保存项目配置。

　　建议把组成软件的程序集一起加入项目，即使其中部分不需要保护，也方便检查依赖并形成完整输出。输入文件应来自同一次构建，避免混入旧版DLL。

　　2、选择重命名范围

　　①切换到【Renaming】，勾选需要进行符号重命名的程序集。

　　②在【Renaming scheme】中选择方案。需要保留异常堆栈还原能力时，可选择【Printable Chars】。

　　③检查【I want to hide public members of my code using cross assembly obfuscation】是否启用。

　　默认情况下，Agile.NET会保留公共成员，方便未参与处理的外部组件引用。启用跨程序集混淆前，应把相关程序集完整加入项目，并检查插件、外部调用方及配置文件是否依赖原名称。可打印字符方案也会修改名称，并不能解决反射兼容问题。

　　3、为反射入口添加排除规则

　　①在【Renaming】中点击【I want to specifically exclude members from the obfuscation】。

　　②在排除设置中定位按名称访问的类型、方法、属性或字段，配置需要保留的项目。

　　③点击【Save】，再点击【Build】生成保护后的程序集。

　　④从输出目录运行程序，验证插件发现、对象创建和成员调用。

　　按完整类型名查找对象时，仅保留方法名可能不够；类型名和命名空间也要检查。通过GetProperty读取配置属性时，则要保留对应属性名称。排除范围应围绕实际访问方式确定。

　　二、Agile.NET混淆后反射调用失效如何排查

　　先区分失败发生在加载程序集、查找类型、查找成员，还是执行方法内部。外层只提示“反射调用异常”，通常不足以判断原因。

　　1、对照映射文件检查名称变化

　　①记录失败调用使用的类型名、成员名，以及运行时实际加载的程序集路径。

　　②打开本次构建生成的名称映射文件，查找相关类型和成员，确认它们是否被重命名。

　　③返回【Renaming】，通过排除入口保留对应名称，重新点击【Build】验证。

　　④若需要进一步缩小范围，可在测试副本中取消目标程序集的重命名，再比较同一调用是否恢复。

　　配置文件中保存的旧类型名、运行时拼接出的成员名，未必能被自动修正。不要因为源码中的字符串没有变化，就认定输出程序集仍有同名成员。

　　2、检查成员查找条件

　　找到类型后，GetMethod仍返回空值，就要继续核对方法名称、参数类型和BindingFlags。

　　①确认调用目标是实例方法还是静态方法，以及是否属于公共成员。

　　②对于重载方法，核对参数数量、顺序和类型，避免只凭名称选择方法。

　　③回到【Renaming】的排除设置，确认选中的是实际调用的成员。

　　④重新【Build】，同时测试正常参数和边界参数下的调用结果。

　　保留类名不会自动保证所有成员名都保留。继承成员、非公共方法和重载方法，也不能只按界面中看到的简称判断。

　　3、检查异常内部原因

　　TargetInvocationException通常表示被调用方法抛出了异常，应继续查看InnerException。此时名称查找可能已经成功，问题也可能发生在依赖加载、初始化或业务逻辑中。

　　①保存完整异常及内部异常，保留本次输出对应的映射文件。

　　②若同时启用了其他保护，在测试副本中分别检查【Method Call Obfuscation】和【Code Encryption】的程序集勾选状态，每次只改变一项再构建。

　　③若单独部署代码加密运行组件，核对文件是否齐全、进程位数是否匹配。

　　④确认部署目录没有同时保留新旧版本DLL，再重复失败场景。

　　4、检查源码中的混淆特性

　　①查找目标类型和成员上的System.Reflection.ObfuscationAttribute，核对Exclude与ApplyToMembers设置。

　　②检查成员自身是否有覆盖类型设置的特性。Agile.NET会优先考虑成员上的声明。

　　③重新编译源码，再回到Agile.NET点击【Build】，确保处理的是包含最新特性的程序集。

　　源码声明发生变化后，只重新处理旧DLL不会生效。使用属性控制时，还应避免无意中把整类成员全部排除。

　　三、Agile.NET混淆规则调整后如何验证发布结果

　　反射问题修复后，还要确认正式构建确实使用了这份配置。手动测试通过、流水线仍失败，常见于项目文件或输入路径不同。

　　1、保存可重复使用的项目配置

　　①点击【Save】下方箭头→【Save As...】，将验证通过的配置另存为发布项目。

　　②在构建任务中核对/Project指向的文件，以及程序集输入路径、输出路径。

　　③再次运行保护流程，使用最终输出文件执行插件加载、序列化及反射调用测试。

　　需要只替换部分程序集的补丁发布，还应评估是否复用上一版名称映射，避免不同批次的名称关系不一致。

　　2、保存并还原异常堆栈

　　①点击主功能区的【Decode Stack Trace】，选择出错版本对应的映射文件。

　　②把异常堆栈粘贴到【Obfuscated Stack Trace】，点击【Decode】。

　　③查看【Decoded Stack Trace】，将还原位置与源码版本对应。

　　映射文件应与每次发布结果一起内部留存，避免使用其他版本的映射解释当前异常。

　　总结

　　反射把一部分调用关系留到了运行时，插件名称、配置项和属性名称因此也成了程序需要遵守的约定。Agile.NET的规则配置越贴近这些实际约定，后续升级就越容易维护。团队可以把必须保留的入口及其原因记录下来，新增插件或调整接口时一并检查，避免等到发布后才发现动态调用失效。希望这篇文章能帮助大家找准混淆与反射之间的兼容边界，减少反复试配的时间。后续有其他Agile.NET配置或异常分析问题，也欢迎继续交流。