很多人把Agile.NET用到Web项目里时，最担心的不是能不能加保护，而是上线后会不会突然在IIS上报错。这个担心很正常，因为桌面程序报错和ASP.NET项目报错不是一回事，Web端一旦牵涉到应用程序池位数、程序集引用链、反射调用和服务器部署目录，问题就容易看起来像是“保护后不兼容”。从SecureTeam官方兼容矩阵来看，Agile.NET面向的是.NET Framework家族，表格里明确把.NET 2.0及以上的WinForms、WPF、ASP.NET等列为支持类型，而且代码虚拟化、代码加密、重命名、方法调用混淆、字符串混淆、资源加密、控制流混淆和程序集合并在这一类应用上都标为可用。

很多人碰到Agile.NET运行时报错，第一反应都是去找某个固定DLL，但这个问题如果不先分清保护类型，很容易越找越乱。按SecureTeam当前官方文档，真正明确会额外引入原生运行时组件的是Code Encryption，也就是代码加密；它会增加需要随软件一起分发的native component，并同时提供x86和x64两个版本。更关键的是，这个运行时组件默认会被直接嵌进受保护程序集，所以不少项目实际上根本看不到单独的运行时文件。也就是说，先判断你有没有启用代码加密，再判断是否关闭了运行时嵌入，比一上来就在目录里盲找更有效。

Agile.NET反篡改怎么启用Agile.NET校验失败导致启动退出怎么查，这个题目里最容易混淆的一点，是把代码保护里的各种混淆功能和许可证防篡改校验当成同一件事。就SecureTeam公开文档来看，真正直接对应“防篡改校验”的主线，是Agile.net Copy Protection里的公私钥、许可证签名和运行时【Validate】校验流程，而不是单独一个孤立的“反篡改开关”。也就是说，你要启用的核心不是随手勾一个选项，而是先把项目接入Copy Protection，再让程序在启动或关键功能入口做许可证校验。

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

在Agile.NET里做代码虚拟化，最容易走偏的地方，不是不会勾选功能，而是把“适合虚拟化的方法”和“应该覆盖多大范围”混成一件事。SecureTeam官方文档把这两层分得很清楚。虚拟化本质上是把选中的MSIL方法转换成只被内部虚拟机理解的虚拟指令，而且是按方法级来选，不是默认把整套程序集一起虚拟化；同时，官方又专门给了方法选择建议、性能提示和不适用场景。这意味着真正稳的做法，不是先求覆盖面最大，而是先挑对方法，再控制范围。

很多人在Agile.NET里一开【Code Encryption】，第一反应就是包体突然变大了，于是下意识怀疑是不是加密本身把程序集“撑胖”了。真往官方说明里看，主要增量并不只来自方法级加密，而是来自随加密一起加入的本地运行时组件；默认情况下，Agile.NET会把x86和x64两套运行时都直接嵌进加密后的程序集里，如果再勾上防调试，运行时DLL体积还会继续上升。也正因为这样，这类问题不能只盯着“加密开没开”，而要回到运行时组件、嵌入方式和保护层级一起看。

做.NET程序保护时，字符串通常是最容易先暴露业务意图的一层。Agile.NET官方文档把字符串保护放在独立的String Obfuscation功能里，目标就是把程序集string heap里的字面量隐藏起来，减少像授权提示、接口地址、连接信息这类明文直接暴露的情况；同时，官方也把它归在分层保护的一部分，建议和代码加密、虚拟化、重命名等能力配合使用，而不是只开一个选项就指望把所有风险都压住。

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

在Agile.NET里，很多人说的白名单，并不是单独一张名单文件，而是把不能改名、不能被误混淆的类型和成员提前排除出去。官方文档里对这件事的口径很清楚，符号重命名带来的异常，常见根源就是反射依赖；工具会自动识别一部分，但识别不到的部分，需要你自己补exclusions，或者直接在代码里用ObfuscationAttribute声明放行。

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