软件在发布之后，对问题进行修复、补充功能或者调整依赖，这些都是很平常的操作。Obsidium保护后的程序更新要怎样处理，旧授权在更新版本时又该怎么延续，其中的关键是把程序文件的更新和许可证的策略分开来对待。新版程序应当从全新的原始文件开始重新执行保护流程，不要用那些已经保护过的旧文件接着进行覆盖加工。至于旧的授权还能不能继续使用，这要看新版是不是沿用了原先的许可证体系、硬件绑定方式以及校验逻辑。Obsidium内部提供了长密钥和短密钥两套授权系统，它们支持设置有效期、硬件绑定，还能对许可证相关代码进行加密，并且在密钥当中保存附加数据，这些能力很适合按照项目来设计升级的规则。

　　一、Obsidium保护后程序更新怎么处理

　　Obsidium在处理程序更新的时候，需要保留一份未经保护的发布基线，后续的每一次发布，都要从新编译出来的文件开始生成保护包，这样才能避免旧的壳、旧的配置和新代码混到一块儿。

　　1、保留原始构建文件

　　要把那些未经保护的EXE、DLL，还有配置文件和版本说明都保存下来，在修复代码之后，重新完成一次Release构建，再把新生成的输出文件导入到原有的Obsidium项目里面。这个时候，千万不要直接把新的DLL复制进旧的保护包中，因为文件完整性检查和依赖关系很可能因此就对不上了。

　　2、复用保护项目配置

　　打开上一版的项目文件，仔细核对代码加密、完整性检查、水印、试用限制以及许可证设置这些选项，确认全都没有问题之后，再把输入文件替换掉，重新生成新版的程序。Obsidium也提供了命令行的版本，这样可以把保护动作接入到编译和发布的流程里，从而减少手工操作带来的遗漏。

　　3、重新检查依赖文件

　　程序在升级之后，如果新增了DLL、配置文件或者数据文件，就需要同步检查一下保护的范围，当启用了File Integrity Checks功能时，也要把需要校验的文件清单一并更新。这个功能的作用，是让程序在启动时去检查指定的文件，一旦发现未经授权的修改，就拒绝继续运行。

　　4、保留版本输出目录

　　每个版本的输出目录都应当单独保留下来，例如按照产品名、版本号以及构建日期来拆分目录，把原始文件、保护后的文件、项目配置和测试记录放在一起，这样后续一旦出现问题，回溯起来就会容易很多。

　　二、Obsidium更新版本时旧授权怎么延续

　　在Obsidium更新版本的时候，旧的授权能不能延续，首先得由产品策略来决定，有一些小版本的升级，允许老用户直接使用新版本；而另一些功能性的升级，则需要重新获取授权；还有的客户只有在维护期内，才能享有新版本的权利。

　　1、沿用原有许可证参数

　　如果希望旧授权继续有效，那么新版就应当沿用原来的许可证类型、密钥生成的配置，还有应用端的校验逻辑，在没有迁移方案的情况下，不要随随便便就去更换密钥体系，要不然旧用户在升级之后，很可能会被系统识别成未授权的状态。

　　2、用附加数据控制升级范围

　　Obsidium支持在许可证密钥当中保存附加的数据，利用这一点可以搭建出自己定义的授权模型，例如把产品版本、功能模块、维护截止时间这些信息都写进授权数据里，然后由程序自己去判断，这个许可证到底能不能用在当前的版本上。

　　3、区分继续使用和重新发证

　　小版本的修复，完全可以让旧授权接着用；但大版本的升级要是新增了收费的模块，就可以选择重新生成许可证，或者只给原来的许可证补充上相应的升级权限。不要一上来就把所有旧密钥全部作废，这么干的话，客服和交付那边的压力会一下子变得很大。

　　4、谨慎处理黑名单

　　Obsidium还具备黑名单功能，可以把那些已经泄露或者存在风险的许可证添加进去，让它们在后续的版本中失去效力，不过，这个功能比较适合用来对付那些明确有异常的密钥，不太适合当成一种普通的升级手段来用。

　　三、Obsidium版本更新后怎样验证授权

　　Obsidium版本更新之后，需要对老许可证、新许可证还有异常的许可证分别进行测试，光靠验证一下新版能不能打开是远远不够的，旧用户的升级链路，也应当从头到尾完整地跑上一遍。

　　1、测试旧授权升级

　　先准备好上一版已经激活的测试环境，然后用覆盖安装的方式把新版程序装上去，再检查它能不能正常启动、进入核心功能，以及能不能正确读取授权信息，如果涉及到硬件绑定，还要确认原来那套设备指纹的规则有没有被意外改动过。

　　2、测试新授权激活

　　在一个干净的环境里安装新版程序，再用新生成的许可证去完成激活流程，随后检查它的有效期、功能范围、硬件锁定情况，还有到期的提示信息，看是不是都符合当前版本的要求。

　　3、测试异常场景

　　接着，要分别验证许可证缺失、密钥错误、已经过期、硬件发生变化，以及被列入黑名单这几种状态，每一种异常情况，都应该给出清楚的提示，别让用户只看到程序打不开，却压根搞不清问题到底出在哪个地方。

　　4、记录授权兼容关系

　　发布记录里面要写明白，哪些旧版本的许可证还能够继续使用，哪些客户需要补发授权，又有哪些许可证已经被停止使用了，只有当升级策略白纸黑字写得清清楚楚，销售、客服和研发这几个部门在碰到问题时，才不至于各说一套。

　　总结

　　从表面上看，程序更新好像只是替换一下文件，但真正容易出问题的地方，其实是授权兼容的那层关系。Obsidium保护之后程序更新怎么处理，Obsidium更新版本时旧的授权又该怎么延续，整个操作顺序可以大致归纳如下：先从新版的原始文件开始重新执行保护，接着复用并核对好原来的项目配置，然后依照产品策略来决定旧密钥是否继续保持有效，最后再通过老用户升级、新用户激活以及异常授权这三类场景来加以验证。按照这个顺序走下来，发布出去的新版本不但能够正常地起到保护作用，而且也不会让原有的客户在升级之后突然间就失去了授权。