.NET程序通过字符串加载类型时，混淆前运行正常，混淆后却可能返回空值，甚至直接抛出类型加载异常。处理Agile.NET怎么处理反射调用Agile.NET混淆后反射找不到类型如何定位，重点是找出哪些类型名称被写在字符串、配置文件或插件清单里，再针对这些入口设置排除。

　　一、Agile.NET怎么处理反射调用

　　Agile.NET的符号重命名会修改类型、方法和字段名称。普通代码引用会随程序集一起更新，字符串形式的类型名称却可能继续保留旧值，这也是反射调用容易出问题的地方。Agile.NET会自动识别部分反射依赖，识别不到的情况需要手动排除。

　　1、先找出字符串形式的反射入口

　　常见情况包括Type.GetType()、Assembly.GetType()、CreateInstance()以及通过配置文件加载插件。

　　①搜索项目中的Type.GetType和Assembly.GetType。

　　②检查类型名称是否直接写成字符串。

　　③查看JSON、XML或数据库中是否保存了类全名。

　　④记录这些类型及其反射调用成员。

　　例如：

　　这里同时依赖命名空间、类名和程序集名称。类名被重命名后，原字符串就可能找不到目标。

　　2、在Agile.NET中排除反射类型

　　确定需要保留的类型后，可以在项目中添加重命名排除。

　　①打开Agile.NET项目。

　　②进入【Renaming】页面。

　　③确认目标程序集已经勾选。

　　④单击【I want to specifically exclude members from the obfuscation】。

　　⑤找到反射调用涉及的类型或成员。

　　⑥保存项目并重新执行保护。

　　排除范围尽量小一些。反射只依赖类名时，可以先保留类型；如果还会按照字符串查找方法或属性，再把对应成员一起排除。

　　3、用属性在源码中声明排除

　　排除规则需要跟着源码和版本一起管理时，可以使用ObfuscationAttribute。

　　①在目标文件中引用【System.Reflection】。

　　②给反射类型添加Obfuscation属性。

　　③将Exclude设为true。

　　④需要保留成员名称时，将ApplyToMembers设为true。

　　⑤重新编译原程序集，再进行混淆。

　　Exclude默认值为true；ApplyToMembers为true时，排除会继续作用到类型成员。成员自己带有属性时，成员级设置优先。

　　4、处理跨程序集反射调用

　　类型位于另一个DLL时，还要检查两个程序集是否都加入了Agile.NET项目。

　　①列出主程序和被反射加载的DLL。

　　②确认相关程序集均已加入项目。

　　③检查是否启用了跨程序集混淆。

　　④无法统一处理的外部接口应保留公共名称。

　　启用跨程序集混淆后，参与引用的程序集需要一起加入项目。少放一个DLL，调用端与被调用端的名称就可能对不上。

　　二、Agile.NET混淆后反射找不到类型如何定位

　　出现问题后，单纯把整个程序集排除虽然省事，却会明显缩小保护范围。更稳的做法是先确定失败发生在程序集加载、类型查找，还是成员调用阶段。

　　1、记录完整异常和查找字符串

　　①记录TypeLoadException、FileNotFoundException等异常。

　　②输出传给反射API的完整字符串。

　　③记录当前已加载的程序集名称。

　　④确认失败发生在测试版还是混淆版。

　　建议暂时启用明确报错：

　　Type.GetType()查找其他程序集中的类型时，通常需要程序集限定名称；Assembly.GetType()则在指定程序集内部按完整类型名查找。名称缺少命名空间、程序集填错或大小写不一致，都可能导致返回空值。

　　2、检查类型名称是否已经被改写

　　①用反编译工具打开混淆后的程序集。

　　②查找原命名空间和类名。

　　③确认目标类型是否已经改成其他名称。

　　④检查配置文件是否仍保存旧名称。

　　⑤为该类型添加排除后重新构建。

　　未混淆版本可以找到，混淆版本找不到，而且配置仍引用原类名，基本就能把问题锁定在符号重命名上。

　　3、检查排除范围是否少了一层

　　类名保留了，调用GetMethod()或GetProperty()仍然失败，通常是成员名称继续被重命名。

　　①检查ApplyToMembers是否为true。

　　②查看方法、属性上是否有相反的成员级规则。

　　③确认反射是否使用了非公开成员。

　　④只排除实际通过名称查找的成员。

　　别看到类名没变就以为规则已经完整生效。反射调用链里，类型、构造函数、方法和属性都可能单独成为查找目标。

　　4、核对构建使用的项目配置

　　本地调整有效，持续集成构建仍然报错时，通常要查实际使用的项目文件。

　　①确认源码和Release程序集已经重新生成。

　　②检查Agile.NET的输入文件修改时间。

　　③核对命令中的【/Project】路径。

　　④清理旧的保护输出目录。

　　⑤重新执行构建并检查退出码。

　　Agile.NET命令行会通过/Project读取保护设置。流水线继续使用旧项目文件，刚添加的反射排除自然不会进入成品。

　　三、反射问题修复后怎么验证

　　反射修复不能只看程序能否启动。最好围绕实际加载过程做一组小测试，避免某个插件或序列化场景到了用户环境才出问题。

　　1、建立反射调用验证清单

　　①测试每个字符串形式的类型名称。

　　②创建目标类型实例。

　　③调用反射涉及的方法和属性。

　　④覆盖插件、序列化和配置加载场景。

　　⑤分别运行未混淆版与混淆版。

　　能改成强类型引用的地方，可以优先使用typeof(T)、泛型注册或接口映射，减少手写类全名。确实需要动态加载时，再保留必要名称。

　　2、保留对应版本的映射文件

　　Agile.NET执行符号重命名时可以生成映射文件，用于记录原始名称与混淆后名称之间的关系。

　　程序报错后，可打开堆栈解码工具，选择本次发布生成的映射文件，再粘贴混淆堆栈进行还原。映射文件必须与发布版本对应，拿错版本后，定位结果也会跟着偏。

　　总结

　　处理Agile.NET怎么处理反射调用Agile.NET混淆后反射找不到类型如何定位，核心是找出字符串依赖的类型和成员，再做小范围排除。排查时从异常信息、程序集加载、类型全名和成员名称逐层确认，别直接放开整个项目。希望本文能为大家处理Agile.NET混淆后的反射问题提供参考，如需进一步了解相关内容，可联系咨询。