Agile.NET做保护时，最容易出问题的不是功能开关本身，而是保护范围划得太大，结果把反射、跨程序集调用和外部接口一起打乱。官方文档已经给出两个很关键的口径，一是项目里建议把整套软件涉及的程序集都加入工程，哪怕其中一部分最终不保护；二是重命名对反射和某些外部依赖场景可能引入错误，因此排除规则要先于大范围保护来设计。

　　一、Agile.NET排除规则怎么加

　　排除规则的核心，不是把问题模块临时删掉，而是把“哪些成员不能改名、哪些程序集只参与依赖解析不参与保护”这两层边界先定清楚。这样后面即使切版本、发补丁，口径也不会漂。

　　1、先把全部相关程序集加入项目，再决定谁保护谁排除

　　官方说明里明确建议把组成软件的所有程序集都加入项目，即使其中一些不打算保护，因为Agile.NET会基于整套程序集关系做分析，并把未保护程序集一起复制到输出目录。

　　2、先从重命名排除做起，不要一上来全局关保护

　　Agile.NET在重命名文档里说明，反射API以及被你软件引用的某些库，可能因符号改名产生意外错误；工具会自动识别一部分，但官方也保留了手动排除入口，也就是界面里的“指定排除成员”。

　　3、排除优先落在类、方法和公开接口层

　　如果某段代码会被反射按名字查找，或会被外部组件、脚本、插件、序列化框架直接点名调用，优先把对应类、方法、属性加入排除，而不是把整套程序集都取消保护。这样既能保住主干保护强度，也能控制兼容性。这个结论是基于官方对反射风险和公开成员默认不改名的说明做出的工程化建议。

　　4、跨程序集场景先决定是否开启Cross Assembly Obfuscation

　　官方明确写到，默认不会混淆选中程序集里的公开成员，否则外部未纳入改名流程的程序集将无法正常引用；只有在你确认整套软件都纳入同一项目并共同参与改名时，才适合启用跨程序集改名。

　　5、补丁版本要复用旧映射而不是重开新口径

　　如果后续会发补丁版，官方建议复用前一版的obfuscation map，让类和方法沿用旧名映射。这样旧版日志、异常堆栈和补丁兼容性都更稳定，也能减少你每次重新调整排除规则的成本。

　　二、Agile.NET哪些程序集不建议保护

　　这里说的不建议保护，不是绝对不能保护，而是“不建议默认全量上强保护”。判断原则要看两件事，一是该程序集是否承担公开接口角色，二是它是否处在官方列出的能力限制范围内。

　　1、给外部程序调用的类库，不建议默认开启跨程序集改名

　　官方已经说明，若软件会被外部组件当库来引用，公开成员默认不改名更安全；只有你确认没有外部引用，才建议开启跨程序集改名。因此公共SDK、插件接口库、对外开放API库，不建议默认做高强度公开成员改名。

　　2、强依赖反射、按名称查找成员的程序集，不建议先上重命名

　　官方直接指出，反射API和某些被引用库会因为改名带来意外错误，所以这类程序集应先做排除，再决定是否保留其他保护，例如字符串混淆或资源加密，而不是一开始就全量改名。

　　3、受平台限制的应用类型，不建议套用通用强保护模板

　　官方兼容矩阵写得很清楚，代码虚拟化、代码加密和方法调用混淆主要适用于.NET 2.0及以上常规应用，例如WinForms、WPF、ASP.NET；而.NET Compact Framework、Silverlight、Windows Phone、XNA、Windows Store Apps这类类型并不支持全部能力。对这些程序集，不能按桌面应用的通用保护模板直接套。

　　4、高计算密度的核心热路径程序集，不建议直接做方法虚拟化

　　官方在代码虚拟化文档里说明，包含复杂迭代计算的方法可能让受保护版本明显慢于未保护版本，建议优先保护入口或网关方法，而不是直接保护高频运算方法本身。若某程序集主要是图像处理、批量计算、数值循环，这类模块不建议先上重虚拟化。

　　5、只作为依赖存在的第三方程序集，不建议盲目保护

　　从官方“把全部程序集加入项目，但未必都保护”的设计可以看出，第三方依赖完全可以只加入项目参与依赖分析和输出复制，而不一定对它们施加同等保护。对无法完全掌握内部实现的第三方库，这通常是更稳的做法。

　　三、Agile.NET排除与保护范围怎么验收

　　排除规则和保护范围定完后，不做验收等于没定。最稳的做法是用同一套项目文件、同一套程序集集合和两组构建结果去做对照，把兼容性问题压到上线前。

　　1、先做一个不改规则的基准包

　　保留一份当前稳定项目文件和输出结果，作为后面任何调整的比较基准。因为Agile.NET项目本身就保存程序集与保护设置，这一步非常关键。

　　2、每次只改一类排除或一类保护项

　　不要同时改映射、改跨程序集改名、改虚拟化范围，否则出了问题很难判断是哪一项引入。按单变量方式推进，定位会快很多。

　　3、验收优先看三类路径

　　第一类是启动与主流程，第二类是反射、插件、序列化等按名称取成员的路径，第三类是高频性能路径。前两类验证兼容性，后一类验证性能边界。

　　4、把最终口径写回项目说明

　　至少写清哪些程序集只参与依赖分析不参与保护，哪些成员做了排除，哪些程序集不启用高强度保护，后续换版本或换人接手时才能保持一致。

　　总结

　　Agile.NET加排除规则，最稳的顺序是先把所有相关程序集纳入项目，再基于反射、公开接口和跨程序集引用去加成员级排除，而不是先大面积关闭保护。哪些程序集不建议保护，重点看是否承担外部接口角色、是否落在官方能力限制范围内、以及是否属于高频热路径或第三方依赖。把这些边界固化到项目文件和验收清单里，后续保护强度和兼容性才不会反复拉扯。