做自有.NET程序集保护时，最容易出问题的不是工具能不能跑，而是保护后的程序集还能不能正常启动、签名还能不能通过、发布链路能不能稳定复现。Agile.NET官方手册给出的主流程很清楚，先建项目、再加入程序集、再配置保护动作、最后执行构建；项目配置会保存为可复用的工程文件，后续还能接到命令行和MSBuild里。
一、Agile.NET怎么保护程序集
这一段最重要的不是把所有保护选项一次开满，而是先把要保护的程序集边界、签名方式和输出目录定稳，再用一轮可验证的最小保护把流程跑通。Agile.NET官方文档说明，项目里可以加入组成软件的多个程序集，工具会按所选保护操作生成保护后的输出。
1、先把程序集按角色分层
优先区分主程序、核心业务库、第三方依赖库和只做资源承载的程序集，真正需要重点保护的通常是自研核心逻辑；第三方库先保持保守处理，避免一上来把所有依赖一起处理后很难定位兼容问题。
2、在Agile.NET里新建项目并加入程序集
官方文档建议先创建一个新项目，再把软件涉及的程序集加入工程；它还特别提醒，即使某些程序集不准备重点保护，也建议一起加入项目，工具会把它们复制到输出目录，便于形成完整可运行产物。
3、强名称程序集要同步准备签名文件
如果你的程序集本身带强名称签名，Agile.NET项目里要配置同一把签名文件，工具会在保护完成后重新签名；这一步如果漏掉，最常见的结果就是保护后程序集无法被正常加载。
4、保护策略先从保守组合开始
官方列出的保护类型包括代码虚拟化、代码加密、符号重命名、方法调用混淆、字符串混淆、资源加密、程序集合并和控制流混淆等，但工程实践里不建议第一次就全部叠加，先从最小可用组合开始，再按模块逐步加严，更容易控制兼容性风险。
5、先用界面方式做一轮人工构建
在第一次落地时，建议先在界面里完成一轮手工构建，确认输出目录中的保护后程序集能够启动、主要功能正常、依赖没有丢失，再把这份项目文件固化下来供后续自动化使用。Agile.NET的构建按钮会按项目配置生成保护后的程序集。
6、把项目文件当成保护口径的唯一来源
Agile.NET会把程序集信息和保护设置保存在项目文件里，而且这个项目文件是XML形式，后续命令行工具可以直接复用它。这样做的价值是，下次发布时不需要靠人工重新点一遍设置，保护口径能保持一致。
二、Agile.NET保护流程如何跑通
要把流程跑通，关键不是“能保护一次”，而是“每次Release都能稳定产出同样结果”。官方文档已经给出两条很清晰的自动化路线，一条是命令行工具，另一条是接入MSBuild。前者适合脚本或流水线，后者适合和现有.csproj或.vbproj直接联动。
1、先用界面版项目文件跑通首版发布
第一轮上线建议先在Agile.NET界面里把Protect工程调到可用状态，并保存工程文件；只有当这份工程文件已经在人工发布里验证通过，再接命令行和流水线，后面的自动化才有稳定基线。
2、命令行发布优先复用工程文件
官方文档说明可以通过AgileDotNet.Console在命令行执行保护流程，并且最稳的方式就是直接传入已有的项目文件，而不是每次用零散参数临时拼装。这样做既能减少人为差异，也方便在CI里复现。
3、接入MSBuild时把触发点放在Release后段
官方给出的MSBuild集成方式，是在项目文件中加入AgileDotNetLocation和AgileDotNetProjectFile，然后在Release条件下的AfterCompile目标里调用保护命令。这样保护动作发生在编译完成之后，既不影响源代码编译，也更方便与正式发布产物对齐。
4、按官方建议从objRelease取输入而不是binRelease
MSBuild集成文档特别强调，创建Agile.NET工程文件时，程序集应从objRelease目录加入，而不是从binRelease加入。这是很关键的落地点，输入路径选错时，常见结果就是自动化构建和手工构建不一致。
5、把未保护产物与保护后产物同时留档
为了排查兼容问题和支持回滚，建议每次发布都保留两份产物，一份是原始Release构建，一份是保护后构建，并把对应的Agile.NET项目文件、构建号和输出目录一起归档。这样一旦出现功能异常，你能快速判断是代码变更问题还是保护流程问题。
6、把发布验收做成固定清单
每次跑完保护流程后，至少固定检查四项，程序能否启动、关键模块能否加载、签名是否有效、核心业务路径是否可用。只有这四项都通过，才说明“保护流程跑通”，否则只是“工具执行成功”，两者不是一回事。
三、Agile.NET发布验证与回滚
把程序集保护真正做稳，最后要靠发布验证和回滚机制。官方文档给出了构建完成后的基本结果判断，也提供了命令行退出码；你在工程上要做的，是把这些结果和自己的功能验证、问题定位、回滚策略绑定起来。
1、先固定一套发布前验证矩阵
建议至少覆盖启动验证、登录或主界面初始化、插件或反射相关功能、配置读写、异常处理与日志输出这几类高风险路径，因为这几类最容易在保护后暴露兼容性问题。
2、保留项目文件与映射文件便于排障
Agile.NET命令行支持输出混淆映射文件，这类文件对后续排查异常、解释堆栈和复盘版本差异都很有用。对于正式发布版本，项目文件和映射文件都应当进入受控归档，而不是只保留最终可执行文件。
3、把命令行退出码与构建日志一起存档
官方命令行说明中给出了退出码，0表示成功，1表示出错并伴随警告说明。工程上更稳的做法是把退出码、控制台输出和构建日志一起保存，这样后续看流水线失败时能直接定位是保护阶段失败还是后续发布阶段失败。
4、回滚优先回到上一份已验证工程文件
如果某次保护后程序行为异常，不建议在异常版本上继续叠加修改，先回滚到上一个已验证通过的Agile.NET项目文件和发布配置，重新生成一版稳定产物，再对本次新增变更逐项比对，定位会快很多。
5、每次只调整一类保护变更
无论是提高保护强度，还是扩大保护范围，都建议一次只改一类因素，例如只新增一个程序集，或只调整一组保护策略，改完就跑完整验证。这样后续一旦异常，你能快速知道是哪一类变更触发了问题。
6、把最终口径写成团队规范
当你把首个稳定版本跑通后，建议把输入目录、签名文件、项目文件命名、MSBuild接入位置、验收清单和回滚路径整理成一页规范。后面换人维护时，能直接按同一流程执行，而不是重新摸索一遍。
总结
Agile.NET保护程序集，最稳的做法是先在界面里建立项目、加入程序集、配置保护并完成一次人工构建，再把项目文件固化下来。Agile.NET保护流程跑通，关键是用项目文件统一口径，并通过命令行或MSBuild接到Release构建里，同时把输入目录、签名、输出和验收清单全部标准化。最后再用映射文件归档、发布验证和回滚基线把流程做成闭环，程序集保护才会真正稳定可复用。
