.NET程序开启符号重命名后，反射调用、序列化、XAML绑定和外部接口都可能受到影响。这时就要保留部分类型或成员的原始名称。处理Agile.NET混淆排除规则怎么设置Agile.NET排除规则未生效如何检查，重点是明确排除哪一种保护，并确认实际构建使用了修改后的项目配置。

　　一、Agile.NET混淆排除规则怎么设置

　　Agile.NET默认会重命名程序集内部的类和成员，同时会自动识别部分不宜重命名的对象。自动分析没有覆盖到的反射或框架依赖，可以再加入手动排除。

　　1、在项目中添加重命名排除

　　需要保留类名、方法名或属性名时，可以从重命名设置进入排除列表。

　　①打开Agile.NET项目文件。

　　②切换到【Renaming】页面。

　　③勾选需要执行重命名的程序集。

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

　　⑤在程序集结构中选中目标类型或成员。

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

　　排除范围别一下选得太大。一个属性通过反射调用，通常保留对应属性就够了，没必要把整个程序集都放过。

　　2、使用ObfuscationAttribute排除类

　　规则需要跟随源码管理时，可以使用.NET提供的ObfuscationAttribute。Exclude默认值为true，因此下面的类会被排除：

　　①在源码中引用【System.Reflection】。

　　②把属性添加到目标类型上。

　　③将【Exclude】设为true。

　　④需要包含成员时，将【ApplyToMembers】设为true。

　　⑤重新编译程序集，再运行Agile.NET。

　　ApplyToMembers=true表示规则同时作用于类型成员。若设为false，类名可以保留，成员仍可能继续被重命名。

　　3、只排除指定成员

　　有些类的大部分成员可以混淆，只有序列化属性或反射方法需要保留。这种情况单独标记会更合适。

　　方法上的属性优先级高于类级规则。这样可以精确控制某一个成员，不会把整个类的保护强度都降下来。

　　4、保留跨程序集调用的公共成员

　　Agile.NET默认不会重命名选中程序集的公共成员，避免未参与混淆的外部程序集调用失败。启用跨程序集混淆后，必须把相关程序集都加入同一个项目。

　　①检查程序包含哪些EXE和DLL。

　　②把相互引用的程序集加入同一项目。

　　③确认哪些程序集需要执行重命名。

　　④再决定是否启用跨程序集混淆。

　　少加入一个依赖程序集，调用端还在找旧名称，被调用端却已经改名，运行时就容易报错。

　　二、Agile.NET排除规则未生效如何检查

　　看到排除对象仍被改名，先别马上重复添加规则。源码属性、图形界面设置和命令行项目文件可能不是同一套配置，排查时要按构建链路往回找。

　　1、确认保护的是新编译文件

　　①检查源码已经保存。

　　②重新执行Release编译。

　　③核对输入程序集的修改时间。

　　④清理原来的输出目录。

　　⑤重新运行Agile.NET保护。

　　代码里加了属性，但工具读取的还是旧DLL，规则当然不会生效。这个问题很普通，却也是最容易忽略的一项。

　　2、检查ApplyToMembers设置

　　类名保留了，属性和方法却仍被改名，通常要看ApplyToMembers。

　　①打开目标类的属性标记。

　　②检查【ApplyToMembers】是否为true。

　　③查看成员上是否还有单独属性。

　　④重新编译后再保护。

　　成员自身带有ObfuscationAttribute时，成员规则会覆盖类上的设置。别只看类头部，方法和属性也要顺手检查。

　　3、确认排除的是正确保护类型

　　重命名排除主要控制符号名称，不一定会同时关闭代码加密、字符串保护、控制流混淆或虚拟化。Agile.NET将这些能力作为不同的保护操作管理。

　　如果类名已经保留，但方法体仍然难以反编译，可能说明重命名排除已生效，只是其他保护还开着。先分清是哪一种效果，别把“仍有保护”误判成“排除失败”。

　　4、检查命令行使用的项目文件

　　自动构建通常通过AgileDotNet.Console.exe运行，并使用/Project读取图形界面保存的项目配置。命令没有引用正确项目文件时，刚修改的排除列表不会进入构建。

　　①查看流水线中的Agile.NET命令。

　　②核对【/Project】后的文件路径。

　　③确认项目文件已重新保存。

　　④检查构建服务器上是否仍有旧副本。

　　⑤查看命令退出码和警告信息。

　　本地测试正常、持续集成结果不对时，八成要从这一步查起。

　　三、排除规则怎么验证更稳

　　排除规则有没有生效，不能只看程序是否能启动。最好同时检查反编译结果、运行功能和映射文件。

　　1、建立小范围验证对象

　　①选一个容易识别的测试类。

　　②只排除其中一个方法。

　　③重新生成受保护程序集。

　　④用反编译工具查看名称。

　　⑤运行反射、序列化或绑定功能。

　　测试对象符合预期后，再把规则扩展到正式类型。这样定位快，也不会一开始就放开一大片代码。

　　2、保留映射文件和项目配置

　　Agile.NET可生成混淆映射文件，用于记录原始名称与新名称之间的关系，也能辅助还原混淆后的错误堆栈。

　　每次发布时，建议把项目文件、程序集版本和对应映射文件一起归档。后面出现排除失效或运行异常，能够直接对比到底是哪一轮配置发生了变化。

　　总结

　　Agile.NET排除规则主要用于保留反射、序列化、框架入口和外部接口依赖的名称。分析Agile.NET混淆排除规则怎么设置Agile.NET排除规则未生效如何检查时，要同时查看规则范围、源码属性、输入程序集和构建项目文件。排除尽量做到小而准，保护后再用反编译和实际功能双重验证，会比整库放开稳妥得多。希望本文能为大家配置Agile.NET混淆排除提供参考，如需进一步了解相关内容，可联系咨询。