2

我有一个 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 文件重新安装并继续从那里修补？

4

2 回答 2

5

首先，安装取代的 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-通常-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 属性定位相同的基线。

于 2016-09-17T10:05:52.060 回答
2

根据我的经验，通常的路径是在某个时候创建​​一个重大升级 MSI（请参阅 WiX 重大升级元素）。这个具有新产品代码且版本高于上一个补丁版本（例如 2.0.0）的 MSI 将升级 1.0.0 和 1.0.12 之间的所有版本。然后你开始基于 2.0.0 产品打补丁。

补丁中有一些选项可以通过替换每个整个文件或通过对每个文件进行二进制修补来修补 - 我不确定您使用的是哪个，但显然如果您为一个大文件制作一个小补丁，则该补丁将比如果patch 是对该文件的二进制更新。

于 2016-09-16T18:59:43.120 回答