使用 Wix 补丁进行小幅升级

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，您需要使用旧的过时方法，但我真的不建议这样做。它不仅难以管理，还意味着，例如，如果您修复了先前已删除的补丁中的安全漏洞，则当删除较新的过时补丁时，安全漏洞并未修补。这就是自 MSI 3.0 以来一直存在的取代的美化。

但是，对于您的问题，我不建议这样做。最好 MSP 以基线为目标。是的，它们可能会变大一点，但前提是您要添加内容。如果较新的版本只是更新文件集或其他资源，则针对单个 MSI 的 MSP 永远不会比基础 MSI 大（好吧，MSI + 外部 CAB，因为 CAB 嵌入在 MSP 中并且始终应该如此）。有关小型更新 MSP 的更多信息，请参阅https://blogs.msdn.microsoft.com/heaths/2007/03/30/small-updates-should-usually-target-a-single-baseline/和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 视图不会更改 ProductVersion，因此 MSP 1.0.2 将永远不适用。您应该开始了解这对您来说难以维护的地方（更不用说强制客户必须安装每个以前版本的 MSP，如果他们刚刚从您的 RTM 开始，这对他们来说也不是很好的体验）。

总之，让您的客户轻松。只需使用 MSP 本身的 MsiPatchMetadata 表中的 MinorUpdateTargetRTM 属性来定位相同的基线。