wix - 使用 Wix Patching 进行小幅升级

Question

我有一个 Wix 安装程序，它将程序安装到我已成功制作补丁以实现以下升级的版本:

1.0.0 -> 1.0.1

1.0.0 -> 1.0.2

1.0.1 -> 1.0.2

这行得通我每次都必须制作从 1.0.0 到目标内部版本号的新 .msp 文件。因此，根据我对补丁在幕后如何工作的理解，如果我最初有一个从 1.0.0 到 1.0.1 的补丁，然后我创建了一个从 1.0.0 到 1.0.2 的新补丁，如果我要运行新补丁，旧补丁将被卸载，新补丁将取代它。

如果我的理解是正确的，那么这意味着补丁文件的大小会随着代码更改的增加而继续增加，所以我想要一个解决方案来解决这个问题，在某些时候我会增加次要版本，然后启动修补过程结束。

例如我想这样做:

1.0.0 -> 1.0.12 可以用 patch1.msp 处理。然后我创建一个 patch2.msp，它将开始创建基于版本 1.0.12 的补丁。示例升级路径可能如下所示:

1.0.0 -> patch1.msp -> 1.0.12 -> patch2.msp -> 1.1.0 -> patch3.msp 1.1.0 -> 1.1.x

有什么办法可以实现吗？或者我是否需要使用 .msi 文件重新安装并继续从那里打补丁？

Answer 1

首先，安装替代 MSP 不会删除被替代的 MSP。被取代的 MSP 被简单地标记为被取代(不活动)。如果您稍后删除取代 MSP，之前被取代的 MSP 将重新激活。

要删除 MSP，您需要使用旧的淘汰方法，但我真的不推荐这样做。它不仅难以管理，而且还意味着，例如，如果您修复了先前已删除的补丁中的安全漏洞，则当较新的过时补丁被删除时，安全漏洞将被修复。这就是从微星3.0开始就存在的取代美化。

不过，对于你的问题，我不推荐它。 MSP 最好以基线为目标。是的，它们可能会变得更大一些，但前提是您要添加内容。如果较新的版本只是更新文件集或其他资源，则针对单个 MSI 的 MSP 不应增长到超过基本 MSI(好吧，MSI + 外部 CAB，因为 CAB 嵌入在 MSP 中并且应该始终如此)。参见 https://blogs.msdn.microsoft.com/heaths/2007/03/30/small-updates-should-usually-target-a-single-baseline/有关小型更新 MSP 的更多信息，以及 https://blogs.msdn.microsoft.com/heaths/2006/06/14/cumulative-service-packs-with-minorupdatetargetrtm/了解如何通过次要更新 MSP 支持以单个基线为目标。

但这是可能的。您需要在构建每个补丁时保存升级 MSI，因此当您创建 1.0.1 MSI 以有效地与 1.0.0 进行比较以构建您的 MSP 时，那么当您构建下一个 MSP 时，您需要将 1.0.1 与 1.0 进行比较。 2.不过，这些 MSP 必须是次要更新 MSP。这意味着 ProductVersion 属性包含在补丁创作转换中；否则，MSI 1.0.0 + MSP 1.0.1 View 不会更改 ProductVersion，因此 MSP 1.0.2 永远不适用。您应该开始了解这对您来说难以维护的地方(更不用说迫使客户必须安装每个以前版本的 MSP，如果他们刚刚从您的 RTM 开始，这对他们来说也不是很好的体验)。

总而言之，让您的客户轻松上手。只需使用 MSP 本身的 MsiPatchMetadata 表中的 MinorUpdateTargetRTM 属性以相同的基线为目标。