MSI 安装数据的持久性 [英] Persistence of data for MSI installation

问题描述

MSI 安装会调用我的(本机/C++)自定义操作函数.由于 DLL 是新加载的，并且 MSIEXEC.EXE 进程是为每个函数单独启动的(可调用操作，如 MSI/WiX 脚本中所指定)，我无法在 C/C++ 程序中使用任何全局数据.

The MSI installation would call my (native/C++) custom action functions. Since the DLL is freshly loaded, and the MSIEXEC.EXE process is launched separately for each function (the callable actions, as specified in MSI/WiX script), I cannot use any global data in C/C++ program.

我如何(或在哪里)存储有关安装过程的一些信息?我不能使用命名对象(如共享内存)，因为启动 DLL 以调用操作"函数的进程"将退出，并且操作系统不会保留命名对象.

How (or Where) can I store some information about the installation going on? I cannot use named objects (like shared-memory) as the "process" that launches the DLL to call the "action" function would exit, and OS will not keep the named-object.

我可以使用外部文件来存储，但是我怎么知道(在 DLL 的函数中):

I may use an external file to store, but then how would I know (in the DLL's function):

• 何时删除外部文件.
• 何时发现该函数调用是第一次调用(Action/function call Before="LaunchConditions" 可能会有所帮助，不太确定).

• When to delete the external file.
• When to find that this function call is the first call (Action/function call Before="LaunchConditions" may help, not very sure).

如果我无法删除文件，我就无法知道信息"是最新的还是陈旧的(即属于较早失败/成功的 MSI 运行).

If I cannot delete the file, I cannot know if "information" is current or stale (i.e. belonging to earlier failed/succeeded MSI run).

我听说过临时 MSI 表"，但不确定如何使用它.

"Temporary MSI tables" I have heard of, but not sure how to utilize it.

推荐答案

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

Preserve Settings: I am a little confused what your custom actions do, to be honest. However, it sounds like they preserve settings from an older application and setup version and put them back in place if the MSI fails to install properly?

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

Migration Suggestion (please seriously consider this option): Could you install your new MSI package and delete all shortcuts and access to the old application whilst leaving it installed instead? Your new application version installs to a new path and a new registry hive, and then you migrate all settings on first launch of the new application and then kick off the uninstall of the old application - somehow - or just leave it installed if that is acceptable? Are there COM servers in your old install? Other things that have global registration?

自定义操作禁欲:以上只是避免自定义操作的建议.避免自定义操作的原因有很多(反对自定义操作的宣传片).如果您在应用程序启动时迁移设置，您可以避免所有 sequencing、conditioning、impersonation 问题以及技术问题已经面临(还有更多)与自定义操作使用相关的问题.至关重要的是，您处于熟悉的调试上下文(应用程序启动代码)中，而不是熟悉的设置世界及其糟糕的可调试性.

Custom Action Abstinence: The above is just a suggestion to avoid custom actions. There are many reasons to avoid custom actions (propaganda piece against custom actions). If you migrate settings on application launch you avoid all sequencing, conditioning, impersonation issues along with the technical issues you have already faced (there are many more) associated with custom action use. And crucially you are in a familiar debugging context (application launch code) as opposed to the unfamiliar world of setups and their poor debugability.

保留设置和数据:关于在运行的MSI实例中保存数据和设置，内置机制基本上是使用Session.Property(COMcode>/VBScript) 或 MsiSetProperty (Win32) 调用.这允许您在 MSI 的 Session 对象中保留字符串.某种全局数据.

Preserving Settings & Data: With regards to saving data and settings in a running MSI instance, the built in mechanism is basically to set properties using Session.Property (COM / VBScript) or MsiSetProperty (Win32) calls. This allows you to preserve strings inside the MSI's Session object. Sort of global data.

注意，属性只能在立即模式(不改变系统的自定义动作)下设置，将数据发送到延迟模式的自定义动作(可以进行系统更改)是相当的涉及围绕 CustomActionData 概念(更多关于延迟模式和CustomActionData).

Note that properties can only be set in immediate mode (custom actions that don't change the system), and sending the data to deferred mode custom actions (that can make system changes) is quite involved centering around the CustomActionData concept (more on deferred mode & CustomActionData).

本质上，您通过立即模式下的 SetProperty 自定义操作将字符串发送到延迟模式自定义操作.通常是一个自产"分隔的字符串，您在立即模式下构建并在延迟模式下接收它时将其分解为信息片段.您可以尝试 使用 JSON 字符串 和类似的，通过 JSON 字符串序列化和反序列化对象，使传输更容易和更可靠.

Essentially you send a string to the deferred mode custom action by means of a SetProperty custom action in immediate mode. Typically a "home grown" delimited string that you construct in immediate mode and chew up into information pieces when receiving it in deferred mode. You could try to use JSON-strings and similar to make transfer easier and more reliable by serializing and de-serializing objects via JSON strings.

替代方案?:涉及这种设置属性方法.有些人在安装过程中写入 注册表 或写入 临时文件(在临时文件夹中)，然后在 MSI 的提交阶段进行清理，但我不喜欢这种方法有几个原因.一方面，提交自定义操作可能不会根据目标系统上的策略运行 (禁用回滚时，不会创建提交脚本 - 请参阅提交执行"部分)和 这不是最佳做法.添加临时行是一个有趣的选项，我从来没有花太多时间在上面.我怀疑您是否能够轻松地使用它来实现您的需求，尽管我真的不知道您需要什么.我没有正确使用它.快速示例.这个来自 WiX 的 RemoveFile 示例 可能会更好.

Alternatives?: This set property approach is involved. Some people write to and from the registry during installation, or to a temp file (in the temp folder) and then they clean up during the commit phase of MSI, but I don't like this approach for several reasons. For one thing commit custom actions might not run based on policies on target systems (when rollback is disabled, no commit script is created - see "Commit Execution" section), and it isn't best practice. Adding temporary rows is an interesting option that I have never spent much time on. I doubt you would be able to easily use this to achieve what you need, although I don't really know what you need in detail. I haven't used it properly. Quick sample. This RemoveFile example from WiX might be better.

这篇关于MSI 安装数据的持久性的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！