程序未保护时能够启动，经过Agile.NET处理后却停在启动画面，或者直接退出，排查往往会从刚勾选的字符串加密选项开始。不过，同一次处理还可能包含名称重命名、代码加密等操作，输出目录里的依赖文件也可能与原来不同。只有把保护设置和运行条件分开核对，才能判断异常与哪一步有关。以下以Windows下的.NET Framework桌面程序为例，Agile.NET使用英文界面，Visual Studio使用中文界面。

　　一、Agile.NET怎样设置字符串加密保护

　　字符串保护作用于程序集中的字面量字符串，运行时再按需解密。外部配置文件和托管资源属于不同范围，不能仅凭这个选项判断整个安装包中的敏感内容都已受到保护。

　　1、建立独立的保护项目

　　输入程序集与保护输出分开存放，便于保留可正常运行的原版。加入依赖程序集时，也应区分哪些需要保护、哪些只需随程序一起输出。

　　①打开Agile.NET，点击【New】，再点击【Add...】，加入主程序和相关程序集。

　　②将输出目录设为独立文件夹，核对默认生成的【Secured】目录位置。

　　③对已有强名称签名的程序集，选择对应的强名称密钥文件。

　　④点击【Save】，保存本次保护配置。

　　2、启用字符串保护并生成文件

　　①打开【String Obfuscation】，勾选【I want to hide sensitive data such as…】。

　　②检查【Symbol Renaming】、【Code Encryption】等页面，关闭本次对照测试不需要的保护操作。

　　③点击【Build】，完成后从输出目录启动生成的程序。

　　3、确认自动构建使用相同设置

　　①点击【Save】，保存界面中已验证的项目文件。

　　②在构建脚本中核对【/Project】和【/Out】；直接使用命令行参数时，核对是否包含【/SecureStrings】。

　　界面测试通过，脚本生成的文件仍可能使用另一份配置。检查时应对照实际项目路径和输出路径，避免仅凭文件名相同就认定两次处理一致。每次都从未保护的构建产物开始处理，不要把上一次输出重新当作输入。

　　二、Agile.NET字符串加密后程序启动异常如何定位

　　先确认异常能够稳定重现，再缩小保护操作的范围。程序没有窗口、窗口打开后报错和只有调试时退出，排查方向并不相同。

　　1、用相同输入制作两组结果

　　开关对照有参考价值，但输入程序集、依赖和启动方式必须保持一致。如果两次测试使用不同构建版本，结果就难以说明问题。

　　①从同一份未保护程序建立两个测试副本，保留相同配置和数据文件。

　　②在其中一份保护项目的【String Obfuscation】中关闭字符串保护，另一份保持开启。

　　③分别点击【Build】，将输出放入不同目录，以相同参数和工作目录启动。

　　只有开启字符串保护的版本失败时，可以把范围缩小到这项处理及其运行路径，仍需结合异常记录判断具体原因。

　　2、让调试器停在异常发生处

　　①在Visual Studio的【解决方案资源管理器】中右击项目，打开【属性】→【调试】。

　　②选择【启动外部程序】，指向受保护的程序，在【工作目录】中填写对应部署目录。

　　③点击【调试】→【窗口】→【异常设置】，勾选需要捕获的【公共语言运行时异常】。

　　④开始调试，在异常出现后查看【InnerException】和【调用堆栈】，记录异常类型、消息及相关模块。

　　类型初始化异常通常只是外层提示，内部异常才包含更具体的失败原因。例如，启动时读取文件失败，也可能被包装成类型初始化异常。调试时还要核对目标路径，确认运行的是受保护文件，而非项目重新编译出的原版。

　　3、区分加载失败与保护配置冲突

　　缺少文件、程序集位数不匹配，以及反调试设置触发，都可能表现为启动失败。代码加密所需的本机运行组件，也不能直接归因于字符串保护。

　　①遇到【FileNotFoundException】或【FileLoadException】时，记录消息中的程序集名称，核对输出目录里的依赖文件及版本。

　　②遇到【BadImageFormatException】时，在项目【属性】→【生成】中核对【平台目标】，同时检查本机依赖的位数。

　　③同时启用了代码加密时，打开【Code Encryption】，在诊断副本中取消【I want to prevent debugging of protected assemblies】，重新生成。

　　④使用【Disable runtime embedding】配置时，核对本次处理生成的运行组件是否随程序部署。

　　三、Agile.NET怎样核对异常位置并验证修复结果

　　找到异常类型之后，还要把它对应到具体构建和启动环节。尤其是同时启用了重命名的项目，仅看到缩短后的方法名，很难直接找到源码位置。

　　1、使用对应映射文件还原调用堆栈

　　①点击主功能区的【decode stack trace】，打开堆栈解码窗口。

　　②选择发生异常的那次保护构建所生成的映射文件。

　　③将原始堆栈粘贴到【obfuscated stack trace】，点击【decode】。

　　④在【decoded stack trace】中查看还原后的类型和方法，回到源码检查对应调用。

　　映射文件必须与受保护程序集配套，不能随意使用另一次构建的文件。它解决的是重命名后的定位问题，不会自动解释字符串解密为什么失败。检查对应方法时，还应关注它读取的配置、调用的依赖和静态初始化过程。

　　2、围绕失败环节做回归测试

　　只看到主窗口出现，还不足以确认问题已经解决。字符串可能在打开某个页面、加载插件或读取配置时才被访问，启动阶段未触发的路径也要覆盖。

　　①在【String Obfuscation】保持启用的条件下，重新执行原来失败的启动操作。

　　②逐项测试配置读取、插件加载、资源显示和相关业务入口，记录异常是否再次出现。

　　③按项目需要逐项恢复【Symbol Renaming】、【Code Encryption】等保护，每恢复一项便重新生成并测试。

　　④保存本次项目配置、保护输出、映射文件及测试记录，核对部署包采用的是同一批文件。

　　总结

　　Agile.NET的字符串保护可以减少程序集直接暴露的文字线索，为软件保护增加一层处理。它的使用价值还需要与程序兼容性、发布维护和故障定位一起考虑。对开发团队来说，保留清楚的构建对应关系、积累有针对性的测试记录，能够让保护设置更容易维护，也让后续版本更新有据可查。希望这些方法能帮助大家判断启动异常，减少反复尝试配置的时间。如有Agile.NET产品选型或版本配置方面的需求，欢迎联系咨询。