Obsidium命令行保护适合接入Visual Studio构建、批处理脚本和持续集成流程。命令执行后没有生成文件，先别重复运行，问题通常出在授权版本、项目配置、输入输出路径或程序位数上。
一、Obsidium命令行保护怎么配置
Obsidium提供专用命令行版本，可以在程序编译完成后自动执行保护。当前产品分别提供x86和x64版本，使用时要与目标程序架构对应。
1、先确认版本和程序架构
32位程序应使用Obsidium x86，64位程序则使用Obsidium x64。这里别凭Windows系统位数判断，真正要看的是待保护EXE或DLL本身。
①确认目标程序已经完成Release编译。
②检查程序属于x86、x64还是Any CPU。
③选择对应架构的Obsidium版本。
④先在图形界面中测试一次保护。
⑤确认保护后的程序能够正常启动。
图形界面都无法完成保护时，命令行一般也不会突然正常。先把基础配置跑通，后面的自动化会省事很多。
2、在图形界面保存保护项目
命令行保护通常会复用已经配置好的项目。项目中应包含输入程序、输出位置、压缩方式、代码保护和许可策略等内容。
①打开Obsidium图形界面。
②添加准备保护的EXE或DLL。
③设置需要启用的保护功能。
④填写明确的输出目录和文件名。
⑤执行一次手动保护并检查结果。
⑥保存当前项目文件。
项目保存后，再由命令行程序加载它。官方安装包同时提供保护SDK、示例和完整文档，具体命令参数应以当前安装版本附带的命令行说明为准。
3、使用绝对路径执行命令
构建脚本的工作目录经常变化，相对路径在本机能用，放到构建服务器上就可能找不到文件。稳一点，关键路径都写完整。
命令结构可以按下面的方式组织：
"
echo ExitCode=%ERRORLEVEL%
①打开命令行程序的帮助信息。
②确认加载项目文件所需的实际参数。
③给命令行程序和项目文件使用绝对路径。
④将标准输出和错误输出写入日志。
⑤记录命令执行后的退出码。
示例中的参数位置只是结构说明，不能直接照抄。不同架构和版本的实际命令，应从安装目录附带文档中复制，别自己猜参数名称。
4、放到编译完成之后运行
Obsidium命令行保护应在目标程序编译、签名准备和依赖文件生成完成后执行。官方将命令行功能定位为新程序编译后的自动保护入口。
①先执行Release编译。
②确认原始EXE或DLL已经生成。
③再调用Obsidium保护命令。
④检查保护文件是否存在。
⑤通过后再进行打包或发布。
如果保护完又重新编译一次，同名文件可能被编译器覆盖。看起来像“没有生成”，实际是生成后又被后续任务替换了。
二、Obsidium执行命令后没有生成保护文件是什么原因
排查时先看日志和输出目录。光看命令窗口一闪而过，很难判断到底执行了什么。
1、使用了评估版本
这是很容易忽略的一项。Obsidium当前评估版本不能加载和保存项目文件，同时禁用了命令行版本，因此即使安装目录里能看到相关组件，也不能按正式版流程执行自动保护。
①打开Obsidium查看当前授权状态。
②确认使用的不是Evaluation版本。
③检查许可证是否对应当前x86或x64产品。
④重新启动程序后再执行命令。
使用评估版时，继续调整路径和参数通常没什么意义，应先解决版本授权问题。
2、项目仍指向旧的输入文件
项目可能是在另一台电脑上建立的，保存的输入路径仍然指向原目录。
①在图形界面重新打开项目。
②检查输入EXE或DLL是否存在。
③确认项目没有指向Debug目录。
④核对构建后的文件修改时间。
⑤保存项目后重新运行命令。
尤其是流水线切换了工作目录以后，文件名没变，完整路径却早就不一样了。
3、输出文件生成到了其他目录
命令行当前目录、项目所在目录和项目配置的输出目录可能是三个不同位置。
①检查项目中保存的输出路径。
②查看命令执行日志。
③按文件名搜索最新生成的EXE或DLL。
④确认没有把输出路径写到临时目录。
⑤尽量使用独立的保护输出文件夹。
不要默认保护文件一定出现在命令行窗口所在目录。输出位置由项目配置决定时，盯着当前文件夹看半天也找不到。
4、目标文件被占用或没有写入权限
程序仍在运行、调试器没有退出，或者构建服务账号没有目录权限，都会影响文件读取和输出。
①关闭正在运行的目标程序。
②结束调试器和相关测试进程。
③确认输出目录允许创建文件。
④删除同名旧文件后再次执行。
⑤检查安全软件是否隔离了输出文件。
为避免覆盖冲突，可以把原始程序和保护结果放在不同目录。这样出了问题，也不会把未保护文件一起弄丢。
5、程序架构或文件类型不匹配
Obsidium面向32位和64位Windows本机程序，并支持部分.NET Framework 4.x可执行文件。官方产品兼容性说明中列出了EXE、DLL、SCR等类型，但x86和x64需要使用对应版本。
①确认目标文件不是损坏的中间产物。
②检查EXE或DLL的实际架构。
③用对应版本手动打开该文件。
④关闭暂时不需要的高级保护功能。
⑤先尝试生成基础保护文件。
基础保护可以生成，高级配置一开就失败时，再逐项恢复设置。一次把所有选项都关掉或打开，不太容易找出具体原因。
三、Obsidium命令行保护怎么稳定排查
项目比较复杂时，建议做一个最小测试。先证明命令行环境可用，再回头处理正式程序，定位速度会快不少。
1、建立最小保护测试
①准备一个简单的Release版测试程序。
②在图形界面创建独立保护项目。
③手动生成并运行保护文件。
④使用同一项目执行命令行保护。
⑤对比输入、输出和日志结果。
测试程序能生成，正式项目不能生成，问题多半在正式项目路径、文件结构或保护配置；两边都不行，则优先检查授权和命令调用方式。
2、给构建流程增加结果校验
命令执行结束后，不要直接进入发布步骤。脚本应检查退出码、文件是否存在，以及文件修改时间是否属于本次构建。
还可以启动保护后的程序做一次基础测试。文件生成了却打不开，也不能算保护成功。把这些检查固定下来，后面换电脑或调整流水线时会轻松很多。
总结
处理Obsidium命令行保护怎么配置Obsidium执行命令后没有生成保护文件是什么原因，先确认正式授权和程序架构，再检查项目中的输入输出路径、执行日志与构建顺序。别只看命令有没有运行，保护文件是否生成、能否启动才是最终判断依据。希望本文能为大家配置Obsidium自动保护流程提供参考，如需进一步了解相关内容，可联系咨询。
