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

　　一、Agile.NET怎么设置字符串加密

　　Agile.NET中的字符串保护针对程序集里的User Strings。它与资源加密不是同一项功能：普通代码中的字符串常量使用字符串保护，而.resx等托管资源需要使用单独的资源加密功能。

　　1、先建立保护项目

　　①启动Agile.NET，新建保护项目。

　　②点击【Add】加入需要保护的EXE或DLL。一个程序由多个自有程序集组成时，建议把相关程序集一起加入项目。

　　③设置【输出目录】，不要直接覆盖Visual Studio生成的原始程序集。

　　④程序使用强名称签名时，同时配置原项目使用的【强名称密钥】，确保保护后能够重新签名。

　　⑤先保存Agile.NET项目，后续调试时可以在同一套设置基础上逐项修改。

　　官方建议把构成软件的程序集一起加入保护项目，即使其中部分程序集本身不需要执行保护，也可以让输出依赖关系保持完整。

　　2、启用字符串保护

　　使用图形界面时，在保护设置中启用对应的【字符串保护】功能，然后重新生成受保护程序集。通过命令行集成到构建流程时，可以直接使用：

　　AgileDotNet.Console.exe/target:MyApp.exe/SecureStrings/Out:Secured

　　其中【/SecureStrings】用于保护程序集中的用户字符串，也可以使用简写【/us】。Agile.NET会对这些字符串进行加密，并在程序真正请求字符串时再提供解密后的内容。

　　①第一次测试时只启用【字符串保护】，暂时不要同时打开代码虚拟化、方法加密等其他高级保护。

　　②点击【Build】生成保护后的程序集。

　　③从【输出目录】直接运行生成结果，不要把原始目录与保护目录中的DLL混合使用。

　　④基础运行正常后，再逐项增加其他保护功能。

　　这种“单项验证”很重要，因为程序一旦同时启用了多种保护，出现异常后很难判断真正触发问题的是字符串加密还是其他处理。

　　二、字符串加密后程序运行异常如何排查

　　如果未保护版本正常，而启用保护后的版本出现启动失败、功能报错或异常退出，先制作一组只开启字符串加密的对照版本。只要这个版本正常，就可以基本排除字符串保护本身。

　　1、先隔离不同保护功能

　　①复制当前Agile.NET项目，保留原配置作为【基准版本】。

　　②暂时关闭【符号重命名】【代码加密】【代码虚拟化】【资源加密】等功能，只保留【字符串保护】。

　　③重新Build并运行。

　　④只有加入某一项保护后才出现异常，就针对该功能继续排查，不要继续修改字符串设置。

　　⑤对第三方框架、插件接口或反射较多的程序，尤其要检查【符号重命名】是否改变了运行时依赖的类型、属性或方法名称。

　　Agile.NET支持通过排除规则保留不能重命名的符号，官方也指出反射调用、框架入口以及外部依赖名称属于需要特别处理的场景。

　　2、检查保护后的运行环境

　　①确认实际启动的是【保护输出目录】中的EXE，而不是原始EXE搭配部分保护后的DLL。

　　②程序由多个自有DLL组成时，检查这些程序集是否全部来自同一次保护构建。

　　③如果项目关闭了【运行时嵌入】，必须把Agile.NET生成的运行时组件一起部署。

　　④同时存在x86和x64版本时，确认使用了与程序位数匹配的运行时文件。

　　⑤使用强名称程序集时，检查保护后的DLL是否已经正确重新签名。

　　命令行中的【/DisableRuntimeEmbedding】会让运行时组件以独立文件生成，此时这些文件必须跟随程序一起发布；遗漏后就可能造成保护版本无法正常运行。

　　3、区分字符串和资源问题

　　有些程序显示为“文字读取失败”，实际问题来自资源，而不是代码字符串。

　　①如果异常内容来自.resx、图片、语言包或Satellite Assembly，检查是否同时启用了【资源加密】。

　　②使用多语言程序集时，把相关【Satellite Assembly】一起加入Agile.NET项目。

　　③暂时关闭【资源加密】重新Build。如果异常消失，应继续检查资源名称和卫星程序集，而不是调整字符串保护。

　　④普通C#代码中的字符串常量正常，而界面语言、图标或嵌入文件异常时，更应优先按资源问题处理。

　　官方说明中，托管资源由独立的Resource Encryption处理；使用Satellite Assembly时，也建议将这些程序集加入项目，以便保护过程同步处理资源名称。

　　三、运行异常已经出现怎么进一步定位

　　保护后的程序如果只在某些功能路径上报错，应保留异常信息和当次保护配置，通过最小化保护范围确定具体冲突点。

　　1、用异常堆栈定位问题模块

　　①保存当前保护生成的【Map文件】，不要在下一次Build时直接覆盖唯一副本。

　　②收集程序实际异常的完整Stack Trace。

　　③使用Agile.NET的【Decode Stack Trace】功能加载对应Map文件。

　　④将混淆后的调用栈还原，再定位到原始类和方法。

　　⑤找到故障函数后，只调整该模块相关保护设置，再重新验证。

　　Agile.NET会生成映射文件，用于把混淆后的类名和方法名还原为原始符号，这对于保护版本的运行时异常定位非常关键。

　　2、建立逐级保护测试

　　①保存一份【未保护版本】，确认基础功能全部正常。

　　②生成【仅字符串保护】版本并执行核心功能测试。

　　③再依次增加符号混淆、资源加密和代码保护，每增加一层都重新测试。

　　④对启动、配置读取、数据库连接、插件加载和许可证验证等关键路径单独记录结果。

　　⑤确定具体冲突项后，再通过排除或调整保护范围解决，而不是整体关闭安全保护。

　　这种方式能够把保护强度和兼容性问题分开，也更适合后续将Agile.NET集成到MSBuild或CI构建流程中。官方支持通过项目文件和命令行方式把保护步骤加入自动构建。

　　总结

　　Agile.NET字符串保护本身强调的是隐藏程序集中的敏感明文，而不是改变程序原有业务逻辑。保护版本出现运行异常时，最有价值的判断是先确认故障来自字符串、资源还是其他混淆层，再针对具体保护环节处理。通过保留未保护基线、分层验证保护功能和对应Map文件，可以在提高代码保护强度的同时减少兼容性问题。如需进一步了解Agile.NET字符串加密配置、保护后运行异常定位与保护策略调整，欢迎联系咨询。