每一次程序编译完成之后，如果都需要人工打开保护工具、加载工程、点击保护按钮，再把生成的文件复制到发布目录，那么版本一多，就很容易遗漏某些环节。不少人在使用Obsidium时会碰到这样的问题，自然就想知道Obsidium命令行打包该怎么用、命令行参数写错之后又会报什么样的错误。其实，解决这个问题的核心思路并不复杂：先在图形界面里把保护工程调试稳定并保存好，然后让构建脚本去调用命令行版本，自动完成保护。Obsidium官方的文档也提到，命令行版本是可以接入开发环境的，能够在应用程序编译之后自动执行保护流程，并且调用产品的各项保护能力。

　　一、Obsidium命令行打包怎么用

　　如果打算使用命令行方式来打包，最好不要一开始就从空白的参数拼凑。比较稳妥的做法是，先打开Obsidium的图形界面，把输入程序、输出路径、授权规则和保护选项都配置好，并且确认一切正常，之后再把这些设置转到脚本里执行，这样一来，后面排查问题的时候就能节省很多时间。

　　1、先建立保护工程

　　第一步是在Obsidium的可视化窗口里新建一个保护工程，选择你要处理的EXE或者DLL文件，然后分别设置输出目录、需要启用的保护功能，以及许可证相关的规则。把这些都配好后，先手动执行一次保护，生成保护后的文件，接着要去检查一下生成的程序能不能正常启动、授权的流程是不是跑得通，还要看看那些关键的功能有没有出现异常。

　　2、确认安装版本支持命令行

　　在下载页面里，Obsidium明确提到了评估版本是没有办法加载和保存工程文件的，命令行功能也处于被禁用的状态。所以，在正式把自动打包流程用起来之前，一定要先确认好自己手上的授权版本是具备命令行能力的。

　　3、在构建脚本中调用

　　编写构建脚本的时候，把命令行保护这一步放在编译成功之后、生成安装包之前是比较合适的。在脚本里面，需要写清楚保护工程文件的路径、待处理文件的路径和输出位置，而且最好把控制台输出的信息都保存到一个日志文件里。需要注意的是，不同版本下命令行程序的名称和参数格式可能会有一些差异，所以具体参数要依据当前安装包里面自带的文档和帮助信息来填写。Obsidium官方在下载页面也说明了，安装包已经包含了完整的文档和使用示例。

　　4、保护后做基础验证

　　等到脚本跑完之后，不能仅仅检查一下输出文件是不是已经生成了。至少还要去验证程序能否正常启动、许可证读取是否正确、试用限制有没有生效、文件的完整性校验通不通得过，以及核心功能是否完好。因为Obsidium提供了授权、硬件绑定、文件完整性检查等多种能力，你开启的保护功能不一样，需要验证的清单也会随之变化。

　　二、Obsidium命令行参数写错后会报什么错

　　命令行参数写错之后，不同版本给出的提示信息可能会不太一样，但常见的那几类问题其实都是比较集中的。遇到报错的时候，首先应该去看控制台的输出内容和进程的退出状态，不要一上来就反复去修改保护选项，那样反而容易把问题搞复杂。

　　1、参数名称无法识别

　　如果参数拼写有误、横线的格式不对，或者参数的顺序不符合要求，控制台一般会直接报出未知参数、无效选项之类的提示，或者把用法说明显示出来。碰到这种情况，可以先运行一下命令行帮助命令，把正确的参数格式调出来，再一项一项地去核对脚本里的参数，这样就能比较快地定位到问题。

　　2、工程文件无法加载

　　工程文件加载失败的情况也很常见，原因可能是工程路径写错了、文件本身不存在，又或者是评估版不支持加载工程，这些都会让保护任务还没开始就直接退出了。尤其要注意，如果路径里面带有空格，一定要检查脚本是不是已经正确地用引号把路径括了起来。

　　3、输入文件找不到

　　输入文件找不到，往往是因为编译输出的目录发生了变化、文件名被改动了，或者相对路径的起点不对，导致命令行根本找不到要保护的那个文件。在持续集成的环境里面，尤其应该检查当前的工作目录在哪里，不能想当然地认为脚本永远都是在工程的根目录下面执行的。

　　4、输出目录不可写

　　输出目录不可写也是容易踩的坑，常见的情形包括发布目录还没有创建、当前账号没有写入的权限，或者旧的输出文件正被其他进程占用着，这些都会让保护文件无法生成。可以采取的应对办法是，先在脚本里加上创建输出目录的逻辑，然后再去排查杀毒软件、安装包制作程序或者测试进程是不是正占着文件不放。

　　三、Obsidium命令行打包怎样减少返工

　　把命令行方式接入到构建流程之后，还需要把日志、版本记录和回归验证这些环节都固定下来，这样才不至于在某一次发布的时候突然遇到保护异常，搞得手忙脚乱。

　　1、固定工具和工程版本

　　要把Obsidium本身的版本号、保护工程文件还有构建脚本一起纳入版本管理的范围。每次对保护规则做了改动之后，都应该记录下修改了哪些内容、是谁改的，以及这次改动对应的是哪个发布包，这样后期追溯起来就会很清楚。

　　2、保留完整日志

　　日志里面至少需要保留下命令是在什么时间执行的、输入文件的路径、输出路径、退出的状态，还有控制台给出来的提示信息。一旦出现失败的情况，第一步就是根据日志来判断到底是参数的问题、路径的问题、权限的问题，还是授权版本的问题，而不是盲目地去尝试修改配置。

　　3、增加失败阻断

　　当保护步骤没有正常完成的时候，一定要让整个构建流程停下来，绝对不要再接着生成安装包，不然的话，发布目录里面就有可能会混进没有保护的文件，或者上一次构建留下来的旧文件，那样问题就更严重了。

　　总结

　　总的来说，Obsidium的命令行打包很适合放在编译完成之后、安装包生成之前这个阶段来执行。实际用起来的时候，比较推荐的做法是先在图形界面里把工程调通并保存好，再对照当前安装包里的文档来填写命令行的参数。参数写错以后，最常见的表现无非是参数无法识别、工程加载失败、输入文件找不到，或者输出目录不可写。只要把日志、退出状态，还有保护后的验证这几项工作都做到位，自动打包的流程就不容易埋下什么隐患。