MSI安装的数据持久性
Posted
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了MSI安装的数据持久性相关的知识,希望对你有一定的参考价值。
MSI安装将调用我的(本机/ C ++)自定义操作函数。由于DLL是新加载的,并且MSIEXEC.EXE进程是针对每个函数单独启动的(可调用的操作,如MSI / WiX脚本中所指定的),因此我不能在C / C ++程序中使用任何全局数据。
我可以如何(或在哪里)存储有关正在进行的安装的一些信息?我不能使用命名对象(如共享内存)作为启动DLL以调用“动作”函数将退出的“进程”,并且OS将不保留命名对象。
我可以使用外部文件来存储,但是我怎么知道(在DLL的函数中):
- 何时删除外部文件。
- 何时发现此函数调用是第一次调用(动作/函数调用
Before="LaunchConditions"
可能有帮助,不太确定)。
如果我无法删除该文件,我不知道“信息”是当前还是陈旧(即属于早期失败/成功的MSI运行)。
“临时MSI表”我听说过,但不知道如何利用它。
保留设置:说实话,我对你的自定义操作有点困惑。但是,听起来它们保留了较旧的应用程序和安装版本的设置,如果MSI无法正确安装,则将它们放回原位?
迁移建议(请认真考虑此选项):您是否可以安装新的MSI软件包并删除所有快捷方式并访问旧应用程序,而不是安装它?您的新应用程序版本将安装到新路径和新注册表配置单元,然后在首次启动新应用程序时迁移所有设置,然后启动旧应用程序的卸载 - 不知何故 - 或者如果可以接受则将其保留安装?旧安装中是否有COM服务器?其他有全球注册的东西?
自定义操作禁欲:以上只是避免自定义操作的建议。 There are many reasons to avoid custom actions(反对自定义行为的宣传片)。如果您在应用程序启动时迁移设置,则可以避免所有sequencing
,conditioning
,impersonation
问题以及您已经面临的technical issues
(还有更多)与自定义操作使用相关联。至关重要的是,您使用的是熟悉的debugging context
(应用程序启动代码),而不是不熟悉的设置世界及其可调试性差。
保留设置和数据:关于在正在运行的MSI实例中保存数据和设置,内置机制基本上是使用Session.Property
(COM
/ VBScript
)或MsiSetProperty
(Win32
)调用来设置属性。这允许您保留MSI的Session
对象内的字符串。全球数据的排序。
请注意,属性只能在立即模式下设置(不会更改系统的自定义操作),并且将数据发送到延迟模式自定义操作(可以进行系统更改)非常涉及CustomActionData
概念(more on deferred mode & CustomActionData)。
实质上,您通过立即模式下的SetProperty自定义操作将字符串发送到延迟模式自定义操作。通常是一个“自行增长”的分隔字符串,您可以在即时模式下构建,并在延迟模式下接收信息时将其咀嚼成信息片段。您可以尝试使用use JSON-strings和类似方法,通过JSON字符串序列化和反序列化对象,使传输更容易,更可靠。
替代方案?:涉及此集合属性方法。有些人在安装过程中向注册表写入或从临时文件(在临时文件夹中)写入,然后在MSI的提交阶段进行清理,但由于多种原因我不喜欢这种方法。首先,提交自定义操作可能无法基于目标系统上的策略运行(when rollback is disabled, no commit script is created - 请参阅“提交执行”部分)和it isn't best practice。添加临时行是一个有趣的选择,我从来没有花太多时间。我怀疑你是否能够轻松地使用它来实现你所需要的,尽管我真的不知道你需要什么。我没有正确使用它。 Quick sample。 This RemoveFile example from WiX可能会更好。
以上是关于MSI安装的数据持久性的主要内容,如果未能解决你的问题,请参考以下文章