我有一个Wix的安装程序，它将程序安装为我已成功修补的版本，以实现以下升级：
1.0.0 - ＆gt; 1.0.1
1.0.0 - ＆gt; 1.0.2
1.0.1 - ＆gt; 1.0.2
这有效我每次都必须从1.0.0创建新的.msp文件到目标版本号。所以根据我的理解，补丁如何在幕后工作，如果我最初有一个从1.0.0到1.0.1的补丁，那么我创建一个新的从1.0.0到1.0.2，如果我要运行新补丁，旧补丁将被卸载，新补丁将替换它。
如果我的理解是正确的，那么这意味着补丁文件的大小会随着你改变代码的次数而增加，所以我想要一个解决方案来解决这个问题，在某些时候我会增加次要版本，然后开始修补过程结束。
例如我想这样做：
1.0.0 - ＆gt;可以使用patch1.msp处理1.0.12。然后我创建一个patch2.msp，它将开始创建基于版本1.0.12的补丁。然后，示例升级路径可能如下所示：
1.0.0 - ＆gt; patch1.msp - ＆gt; 1.0.12 - ＆gt; patch2.msp - ＆gt; 1.1.0 - ＆gt; patch3.msp 1.1.0 - ＆gt; 1.1.x
有没有办法实现这个目标？或者我是否需要重新安装.msi文件并继续从那里进行修补？
答案 0 :(得分：3)
首先，安装替代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/;有关如何使用次要更新MSP支持定位单个基准，请参见https://blogs.msdn.microsoft.com/heaths/2006/06/14/cumulative-service-packs-with-minorupdatetargetrtm/。
但是，有可能。您需要在构建每个补丁时保存升级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开始，这对他们来说不是很好的体验）。 / p>总而言之，为您的客户保持轻松。只需使用MSP本身的MsiPatchMetadata表中的MinorUpdateTargetRTM属性来定位相同的基线。
答案 1 :(得分：1)
根据我的经验，通常的路径是在某个时候你创建一个主要的升级MSI（参见WiX majorupgrade元素）。具有新ProductCode和版本大于上一个补丁版本（例如2.0.0）的MSI将升级1.0.0和1.0.12之间的所有版本。然后根据2.0.0产品开始修补。
通过替换每个整个文件或通过对每个文件进行二进制修补来修补补丁中的选项 - 我不确定您使用的是哪个，但显然如果您对一个巨大的文件进行小补丁，补丁将会大于补丁是该文件的二进制更新。