自动化发布阶段常常会遇到Agile.NET命令行打包怎么用，以及Agile.NET命令行参数顺序怎么检查的问题；通常情况下，图形界面更适合在前期调整配置，而命令行则更适合被放入批处理、Jenkins、GitLab CI以及Azure DevOps这类构建流程里面；需要注意的是，Agile.NET命令行主要负责的只是“保护程序集”，比如混淆、字符串保护、代码保护和输出受保护文件，其本身并不是单独的安装包制作工具；至于后面的签名、复制依赖、压缩以及生成安装包等操作，则需要由开发人员编写的打包脚本去继续完成。

　　一、Agile.NET命令行打包怎么用

　　在开始编写Agile.NET命令行打包脚本的时候，不建议直接写出过于复杂的脚本；比较稳妥的做法是，开发人员先通过图形界面把保护配置跑通，然后再把固定的配置写进命令行流程当中；通过一些公开的讨论可以看到，在实际的自动化流程里，系统会直接调用AgileDotNet.Console.exe程序，并且配合/Obfuscate、/SecureStrings、/Secure、/Out这些参数来输出受保护的目录。

　　1、先确认命令行程序位置

　　在安装Agile.NET之后，系统一般会同时包含图形界面程序和命令行程序；从部分的安装信息中可以发现，AgileDotNet.Console.exe和AgileDotNet.exe是同时存在的，这表明系统在执行命令行打包时需要调用Console程序，而不是直接去调用图形界面程序；

　　常见的路径定义可以写成如下格式：

　　set AGILE="C:\Program Files (x86)\SecureTeam\AgileDotNet.Console.exe"

　　此外，执行人员也可以先进入到安装目录当中，然后再去执行具体的命令；只要路径里面包含了空格，就必须加上英文的双引号，否则命令行会将路径拆开从而导致识别错误。

　　2、先用最小命令跑通

　　在刚开始配置时，不应该立刻把混淆、字符串加密、代码保护、资源保护、签名和压缩全部写进一条命令里面；可以尝试先只指定目标文件和输出目录，例如：

　　"%AGILE%" /target:"D:\Build\Release\MyApp.exe" /Out:"D:\Build\Protected"

　　若是这个步骤都无法正常输出受保护的文件，那么执行人员就需要先去检查路径、权限以及目标文件是否存在，而不是急着去继续添加其他的保护参数。

　　3、再逐步加入保护参数

　　当最小命令能够正常跑通之后，开发人员就可以在命令里加入混淆、字符串保护、代码保护等参数了，例如：

　　"%AGILE%" /target:"D:\Build\Release\MyApp.exe" /Obfuscate /SecureStrings /Secure /Out:"D:\Build\Protected"

　　在这些参数当中，/Obfuscate通常被用于基础混淆，/SecureStrings被用于字符串保护，而/Secure则倾向于更强的代码保护或加固处理，/Out则用来指定输出的目录；由于不同的版本所支持的参数可能会存在差异，所以在正式编写脚本之前，最好在本机上执行帮助命令，或者查看当前版本的命令行说明，尽量不要完全照搬其他环境下的参数。

　　4、多程序集项目要一起处理

　　如果被保护的项目不是单个exe文件，而是由主程序和多个自研的dll文件组成的，那么建议将这些相互引用的程序集一起放进保护流程里面，示例代码如下：

　　"%AGILE%" /target:"D:\Build\Release\MyApp.exe;D:\Build\Release\Core.dll;D:\Build\Release\Service.dll" /Obfuscate /SecureStrings /Out:"D:\Build\Protected"

　　在此处需要特别注意，多个程序集之间必须使用英文的分号“;”进行分隔，不能写成中文的分号，同时也不要把路径拆成几个不完整的片段；在多程序集的项目当中，如果仅仅保护了其中的某一个dll，而另一个dll却还在按照旧的名称去引用它，系统运行时就很容易出现类型找不到、方法找不到或者引用丢失等各种问题。

　　二、Agile.NET命令行参数顺序怎么检查

　　对于Agile.NET命令行参数的顺序，不建议采用死记硬背的方式；更实际的检查方法是，按照“执行程序—目标文件—保护选项—输出目录—后续处理”的顺序去逐项核对；很多时候，系统报错并不是因为参数本身的顺序错了，而是由于路径没有加引号、输出目录写反、多个dll之间的分隔符错误，或者是保护失败之后脚本依然在继续打包。

　　1、检查命令开头是不是Console程序

　　命令的开头必须是AgileDotNet.Console.exe，执行人员不要把项目文件、exe目标文件或者安装目录直接放置在第一位，例如：

　　"C:\Program Files (x86)\SecureTeam\AgileDotNet.Console.exe"

　　如果CI服务器在运行时提示“不是内部或外部命令”，这大多数是因为路径没有写完整，或者是构建机上没有正确安装Agile.NET的命令行组件。

　　2、检查target路径是否完整

　　在/target参数的后面，需要紧跟需要被保护的exe或dll文件；当只有单个文件时写一个路径即可，而面对多文件时，则需要把多个路径放在同一个参数值里面，并且用英文分号隔开；

　　建议的写法如下：

　　/target:"D:\App\Main.exe;D:\App\Core.dll"

　　3、检查保护参数不要重复堆叠

　　虽然命令里可以加入/Obfuscate、/SecureStrings、/Secure这类的保护参数，但是不应该在每次打包时临时乱加；比如今天加上字符串保护，明天又加上控制流保护，后天再加入资源保护，最后一旦出现问题，就会很难判断是由哪一项参数引起的；更好的做法是先固定好基础的参数，在确认运行稳定之后，再逐项将新参数添加进去。　

　　三、命令行打包出错时怎么定位

　　在Agile.NET命令行出错的时候，不需要把视线总盯着“参数顺序”；真正常见的问题反而经常是构建机环境不一致、路径不一致、依赖没有复制，以及保护项和项目结构发生了冲突；把这些因素拆开来进行检查，定位问题的速度会快很多。

　　1、把CI里的命令拿到本机单独跑

　　若是流水线在运行时失败了，可以先把完整的命令复制出来，在本地的CMD或者PowerShell里面单独运行一下；这样做有助于判断问题到底是由Agile.NET的配置引起的，还是由CI环境引起的；毕竟构建机和开发机在路径、权限、.NET运行时以及工作目录上，都有可能存在不同。

　　2、把输出日志保存下来

　　在编写脚本的时候，建议把Agile.NET的输出信息写入到日志文件当中：

　　"%AGILE%" /target:"D:\Build\Release\MyApp.exe" /Obfuscate /SecureStrings /Out:"D:\Build\Protected" > "D:\Build\Logs\agile.log" 2>&1

　　后续若是遇到了启动失败、引用丢失或者字符串保护异常的情况，就可以回头查看当时到底保护了哪些文件，以及中途有没有报错信息的产生。

　　3、确认依赖文件没有漏复制

　　Agile.NET命令行在输出受保护的程序集之后，并不代表完整的发布包就已经准备就绪了；.config、.json、.deps.json、.runtimeconfig.json、语言包目录、插件目录、图片资源、第三方组件以及native dll等文件，后续都需要被继续复制；很多所谓的“命令行打包失败”，实际上并不是因为保护过程失败了，而是因为保护后的目录不够完整。

总结

　　综上所述，关于Agile.NET命令行打包怎么用的问题，其核心就在于调用AgileDotNet.Console.exe程序，通过/target来指定对应的程序集，利用/Obfuscate、/SecureStrings、/Secure等参数来开启相应的保护，最后再用/Out把结果输出到独立的目录里面；而关于Agile.NET命令行参数顺序怎么检查的问题，也不仅仅是看谁排在前面，而是需要按照执行程序、目标路径、保护参数、输出目录、日志和退出状态来进行逐项的核对；只要路径交代清楚了、输出目录分开了、依赖也复制完整了，命令行保护就可以更加稳定地被放入到正式的发布流程当中了。