MSI安装的数据持久性

时间:2018-09-18 11:24:01

标签: c++ windows wix windows-installer data-persistence

MSI安装将调用我的(本机/ C ++)自定义操作函数。由于DLL是重新加载的,并且针对每个功能(MSI / WiX脚本中指定的可调用操作)分别启动了MSIEXEC.EXE进程,所以我不能在C / C ++程序中使用任何全局数据。

如何(或在哪里)存储有关正在进行的安装的一些信息? 我不能使用命名对象(例如共享内存),因为启动DLL来调用“动作”功能的“进程”将退出,并且OS将不会保留命名对象。

我可能会使用一个外部文件进行存储,但是随后我将如何知道(在DLL的功能中):

  • 何时删除外部文件。
  • 何时发现该函数调用是第一个调用(动作/函数调用Before="LaunchConditions"可能有帮助,但不是很确定)。

如果我无法删除文件,则不知道“信息”是当前还是过时(即属于较早的失败/成功的MSI运行)。

我听说过“临时MSI表”,但不确定如何使用它。

1 个答案:

答案 0 :(得分:1)

保留设置 :老实说,我有点困惑您的自定义操作。但是,听起来好像它们保留了较旧应用程序和安装版本中的设置,如果MSI无法正确安装,则会将它们放回原处?

  

迁移建议 (请认真考虑此选项):您能否安装新的MSI软件包并删除所有快捷方式并在离开旧应用程序的同时访问旧应用程序   代替安装?您的新应用程序版本将安装到新路径   和新的注册表配置单元,然后您首先迁移所有设置   启动新应用程序,然后开始卸载   旧应用程序-不知何故-如果是   可以接受吗?旧安装中有COM服务器吗?其他具有全球注册的东西吗?

自定义动作禁欲 :以上只是避免自定义动作的建议。 There are many reasons to avoid custom actions(针对自定义操作的宣传)。如果您在应用程序启动时迁移设置,则可以避免所有sequencingconditioningimpersonation问题以及与自定义操作相关的technical issues问题(还有更多)采用。而且,至关重要的是,您处于熟悉的debugging context(应用程序启动代码)中,而不是陌生的设置环境及其可调试性差。


保存设置和数据 :关于在运行中的MSI实例中保存数据和设置,内置机制基本上是使用Session.Property设置属性(COM / VBScript)或MsiSetPropertyWin32)个呼叫。这样,您就可以在MSI的 Session 对象中保留字符串。全局数据排序。

请注意,只能在立即模式(不更改系统的自定义操作)中设置属性,并且将数据发送到延迟模式自定义操作(可以进行系统更改)相当涉及围绕CustomActionData概念(more on deferred mode & CustomActionData)。

本质上,您是通过立即模式下的SetProperty自定义操作将字符串发送到延迟模式自定义操作的。通常,您以立即模式构造“定界”定界字符串,并在以延迟模式接收时将其分解为信息片段。您可以尝试use JSON-strings和类似的操作,以通过JSON字符串对对象进行序列化和反序列化,从而使传输更容易,更可靠。

替代方法? :涉及这种 set属性方法。有些人在安装过程中写入注册表或从中写入,或者写入 temp文件(在temp文件夹中),然后在MSI的提交阶段进行清理,但是我有几个原因不喜欢这种方法。一方面,提交自定义操作可能不会基于目标系统上的策略运行(when rollback is disabled, no commit script is created-请参阅“ 提交执行”部分)和it isn't best practice。添加临时行是一个有趣的选择,我从没花太多时间。我怀疑您是否可以轻松地使用此功能来实现所需的功能,尽管我并不十分了解您的详细信息。我没有正确使用它。 Quick sampleThis RemoveFile example from WiX可能更好。

相关问题