安装后删除有效负载的替换 MSI 的 WiX 包 捆绑 mk 1捆绑 mk 2

如何解决安装后删除有效负载的替换 MSI 的 WiX 包 捆绑 mk 1捆绑 mk 2

总结

我有一个正在删除升级文件的包。删除它们是因为旧的 MSI 卸载在新 MSI 安装完成后触发。

由于它们具有具有不同组件 ID 的相同文件，因此引用计数无法阻止它。

我需要确保在安装过程结束时文件存在。

历史

捆绑 mk 1

创建了具有多个 MSI 的两个捆绑包。他们共享一些 MSI，但也有自己独特的内容。

• 从 mk1 升级到 mk1 对两个捆绑包都很好

捆绑 mk 2

其中一个捆绑包已更改为具有一些替代 MSI。它不再有任何共享的 MSI。新的 MSI 具有与以前相同的有效载荷和相同的功能 ID，但具有不同的升级代码和组件 ID。

• 从 mk1 升级 -> mk2 仅适用于未更改的包。
• 从 mk2 升级 -> mk2 对两个捆绑包都适用。
• 从 mk1 升级 -> mk2 导致更改的包丢失有效负载。
• 修复将恢复文件。
• 日志文件显示 mk1 缓存的 MSI 卸载在已安装 mk2 MSI 后触发，这就是删除所有文件的原因。

问题

丢失的文件显然是从mk1到mk2的问题。如果客户从 mk1 升级到 mk2，要求客户进行维修是不切实际的。

我最初尝试将功能强制到本地，直到我找到卸载日志文件并发现 MSI 已经安装正常 - 只是清理在一个意想不到的地方。

我希望我可以改变包序列的顺序，但它似乎没有任何自己的安装执行序列需要调整。

我可以检测到捆绑包何时从 mk1 转到 mk2 并尝试更改内容，但我不知道要更改什么。

也许我需要检测缓存的包并针对它执行命令行卸载？

我不想将自定义操作放入 MSI，但如果这是解决问题的方法，我会这样做。我希望它可以从捆绑包中修复。

考虑的选项

1. 如果是从 mk1 到 mk2 的升级，请让包明确地执行命令行卸载前一个包。
2. 为新的 MSI 分配新的功能 ID，无论如何都要包括 mk1 MSI 的 RTM，强制 mk1 MSI 功能状态为“不存在”并确保 mk2 MSI 在 mk1 MSI 之后运行。
3. 通过使用修复选项调用自身，在捆绑安装结束时强制修复。

实施

加入我已经制定出来的东西会有点工作。它带来了一系列需要解决的新问题。

我在 DetectRelatedBundle 中获得了缓存包的信息。从那里我可以在以下位置之一下查找注册表：

HLKM:Software\Microsoft\Windows\CurrentVersion\Uninstall\<ProductCode>
HLKM:Software\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\<ProductCode>

这为我提供了 InstallSource 注册表项中缓存包的位置。

在 PlanComplete 期间，我会使用缓存包的静默修改功能告诉它删除共享功能，以便在新包放置新文件之前删除它们。

新的问题是：

• 功能无法很好地迁移。它仅安装先前选择的功能，但修改和卸载相信所有功能都存在。
• 如果出错，则无法回滚。
• 我不知道如果我从命令行静默升级未提升的情况下运行会发生什么。这里有潜在的问题。