对于很多.NET项目，在进行保护操作后常常出现运行出错的问题，这通常并非工具本身的问题，而是因为反射、序列化、插件加载及外部调用等代码在被改名或加密后，运行时无法找到原始的类型和成员；因此，关于Agile.NET如何排除不需要保护的类型，以及排除规则应该具体写到哪一层，关键是要先区分清楚需要排除的是具体类型、成员、整个程序集，还是只排除某一类保护动作。根据Agile.NET官方文档，该工具提供了代码虚拟化、代码加密、符号重命名、字符串混淆等多种保护方式，同时也支持通过声明式属性（ObfuscationAttribute）来控制哪些类型和成员不参与混淆。

　　一、Agile.NET怎么排除不需要保护的类型

　　在排除一个类型之前，开发者需要先判断这个类型为什么不能受到保护；常见的对象包括通过反射按名称调用的类、JSON或XML序列化模型、依赖固定成员名的插件接口、WPF或WinForms绑定对象、外部SDK回调类等。如果仅仅因为运行时报错，就盲目排除整个程序集，那么保护范围就会被过度放大和削弱；更好的做法是先确定问题根源。

　　1、先从报错点定位类型

　　开发者可以从运行日志和异常堆栈中找到调用位置，从而确认是哪个类型或成员在保护之后无法正常访问；符号重命名会改变类型、方法和字段的名称，当反射API依赖于原始名称时，混淆之后就可能失败，这一点官方文档中也有说明。

　　2、在项目配置里加排除项

　　如果开发者没有源码，或者不希望修改业务代码，可以在Agile.NET保护项目中进入重命名设置，利用排除成员的配置入口来添加规则；官方文档提到，当符号重命名引发依赖问题时，可以使用类似“排除特定成员不被混淆”这样的选项来添加自定义排除。

　　3、用声明式属性排除

　　当开发者可以修改源码时，可以在需要保留名称的类或成员上添加System.Reflection.ObfuscationAttribute；Agile.NET会读取这个属性，并决定对程序集、类型或成员怎样进行处理，将Exclude设为true则表示不进行混淆，设为false则表示参与混淆。

　　4、保护后做运行验证

　　排除规则加完之后，开发者不能只看构建是否成功，还需要运行登录、接口调用、反射加载、序列化、插件初始化以及关键业务流程，由此确认被豁免的类型能正常工作，同时其他核心代码仍然处在保护范围之内。

　　二、Agile.NET排除规则该写到哪一层

　　对于排除规则应该写到哪一层，基本原则是：能限定在成员层，就不要放宽到类型层；能限定在类型层，就不要放宽到程序集层。排除范围越大，保护效果被削弱的程度也越大。

　　1、成员层适合小范围例外

　　当只有某个方法、属性或字段被反射调用时，开发者应将豁免规则写在成员层，因为这样既可以保留该成员的原始名称，又能让同一类型中的其他成员继续受到保护；例如只需要保留某个回调方法的名字，就不必放开整个类。

　　2、类型层适合模型和接口类

　　像DTO、序列化模型、插件接口、依赖绑定的ViewModel这些类，可以在类型层进行豁免处理；当ApplyToMembers设为true时，规则会应用到该类型的所有成员，如果只想保留类名而不保留成员名，则需要关闭成员应用范围。根据Agile.NET文档，ApplyToMembers控制的是类型或程序集上的规则是否继续应用到成员，而成员自身的属性具有更高优先级。

　　3、程序集层只用于明确边界

　　只有当整个程序集都充当外部接口、二次开发SDK或者需要被反射扫描时，才考虑在程序集层进行例外设置；普通的业务程序集应避免整体跳过，否则核心逻辑的保护效果会明显降低。

　　4、项目配置适合无源码场景

　　对于第三方库、临时交付包、或者无法修改源码的老项目，开发者可以把例外规则写在Agile.NET的项目配置文件中；对于源码可控的长期项目，则更适合将稳定的跳过规则写入源码属性，这样后续构建以及多人协作时更容易保持一致。

　　三、Agile.NET排除规则为什么没有生效

　　排除规则完成后没有生效，原因通常不止一个；需要从规则层级、保护类型、构建产物和运行验证这四个方面来进行排查。

　　1、检查保护动作是否选错

　　有时问题来自符号重命名，有些则来自代码加密或虚拟化；如果只排除了重命名操作，并不能保证方法体在加密后就不会出现运行问题，开发者需要回到Agile.NET项目中确认该类型实际启用了哪些保护动作。

　　2、检查层级是否被覆盖

　　当类型层和成员层同时存在规则时，成员层可能会覆盖类型层的判断；SecureTeam文档也指出，成员自身的ObfuscationAttribute优先级高于类型上设置的ApplyToMembers规则。

　　3、检查是否保护了旧文件

　　需要确认运行时加载的DLL是保护后新生成的文件，而不是旧目录中的缓存文件；很多例外规则看起来没有效果，实际上是因为部署包没有及时更新，或者相关服务仍然在加载旧的程序集。

　　4、检查名称映射和反编译结果

　　在保护完成之后，开发者可以查看Agile.NET生成的映射文件，或者使用反编译工具检查目标类型的名称是否被保留；符号重命名的文档也提到，映射文件可用于补丁版本中的名称映射复用，这也说明映射结果是判断保护效果的重要参考。

　　总结

　　总体而言，关于Agile.NET如何排除不需要保护的类型以及排除规则应该写到哪一层，核心在于控制排除范围；对于反射、序列化、插件接口和外部调用相关的代码，优先在成员层或类型层进行跳过，只有在边界非常明确的情况下，才考虑程序集层。如果源码可以修改，优先使用声明式属性，如果无法修改源码，则使用Agile.NET项目配置文件；规则设置完成之后，还需要通过日志、运行流程、映射文件和反编译结果进行核对，避免为了修正一个运行问题而将过多代码放到保护范围之外。