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

在.NET软件开发中，程序集保护通常会安排在项目发布前进行。开发完成后的程序文件中，类名称、方法结构以及业务逻辑都会保存在编译结果里，如果项目中包含核心功能模块，往往需要通过代码混淆调整程序集的可读性。Agile.NET可以对.NET程序集进行混淆处理，并根据项目情况设置不同保护规则。实际使用时，混淆配置并不是简单开启功能即可完成。项目结构变化、规则匹配范围设置不准确、排除项配置过多，都可能导致部分代码没有进入保护流程。例如某些类名称没有变化，新增模块没有处理，或者输出文件和预期结果存在差异。遇到这类情况，需要从规则本身和项目文件两个方向进行确认。

Agile.NET可以对程序集中的用户字符串进行保护，使许可证信息、连接字符串、接口地址以及程序内部关键文本不再以明文形式直接保存在程序集里。保护后的字符串会在程序实际需要时提供给.NET运行环境，因此正常情况下不应改变字符串本身的业务含义。处理“Agile.NET怎么设置字符串加密，Agile.NET字符串加密后程序运行异常如何排查”时，要先确认异常是否确实由字符串加密引起，再区分程序集保护、运行时组件和其他混淆功能带来的影响。

WPF程序的界面、后台代码、资源字典和数据绑定联系得很紧。Agile.NET处理程序集时，如果重命名了XAML仍要按原名称访问的成员，程序可能编译正常，保护后却出现窗口打不开、样式丢失或绑定失效。解决“Agile.NET怎么保护WPF程序Agile.NET处理XAML后界面加载异常是什么原因”，需要分层启用保护，并单独检查XAML关联对象。

Agile.NET反篡改保护如何开启，以及Agile.NET反篡改触发后软件会出现哪些状况，这些内容都需要和一般的代码混淆区分开；像名字混淆、把字符串加密、改变控制流这些做法，主要作用是让别人反编译时看不太懂，但反篡改保护更注重在运行的时候进行检查，它的主要目的是一旦发现软件被别人修改了、被塞了多余的东西、被换掉或者弄坏了，系统就不会让软件再照常跑下去了；Agile.NET这个.NET保护工具在设计上的主要用途就是为了搞代码混淆、代码保护、防止别人破解和防止被修改，它能够对类名和方法名、资源、字符串、方法的具体实现、系统调用还有库调用这些内容进行防护。

针对Agile.NET代码混淆的设置问题，以及混淆后程序无法启动的解决办法，这类情况通常挺让人头疼的，而且也不是直接把防护功能全部开到最大就能搞定，混淆的主要目的，就是把代码里的那些名字，像什么类、方法、字段，还有里面的字串和运行逻辑，弄得乱七八糟的，别人反编译的时候就很难看懂，其实这个软件自带的功能挺多的，名字弄乱、逻辑打散、字串和文件加密、方法调用捣碎，还有代码虚拟化这些它都能做，管你是普通的电脑软件、网站项目，还是做游戏的Unity，它都能用。

对于.NET程序来说，上线前进行代码混淆是一道很常见的保护步骤，可一旦混淆之后，异常定位的难度就会明显加大。要说清楚Agile.NET混淆后堆栈信息难以定位该怎么办，以及这些用来定位的信息平时又该怎么保留，核心就一件事：必须提前把混淆前后的名称映射关系、准确的版本号，还有异常发生时的上下文都给留存好。Agile.NET在混淆过程中，会改动类、方法、字段之类的元数据，最后留在异常堆栈里的，往往也只剩下那些被改得面目全非的名字；幸好它会同时生成一份map文件，专门用来描述混淆实体和原始名称之间的对应关系，这对于后面解释那些被混淆过的调试输出来说，是非常关键的依据。

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

做Agile.NET反调试，难点通常不在于把功能打开，而在于打开以后程序还能不能稳、出了问题能不能快速回退。公开产品资料能确认两点，一是Agile.NET本身就是面向.NET程序保护的工具，并且强调保护过程可控；二是它在6.6.0.42版本中加入了新的anti debugger技术。也正因为这样，反调试更适合按步骤上，而不是一上来就把整套保护全压到正式包里。

Agile.NET里的控制流混淆，本质上是把原本较直观的方法流程改写成更难还原的等价结构。官方公开功能页对这项能力的描述很明确，它会把方法内部流程改造成更难读懂的代码结构，同时产品也支持输出map file，方便后面把混淆后的异常栈重新对应回原始名称。也正因为这类保护会直接动方法体，开启后最常见的问题不是编译不过，而是程序能发版、上线后某些路径突然崩溃，所以正确做法一定是先小范围开，再结合日志和map file去回查。