2016-09-15 49 views
0

次要升级我有一个维克斯安装该安装程序是版本我已经成功地进行了补丁来实现以下升级:与维克斯修补

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文件并继续从那里进行修补?

回答

3

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

为了删除MSP,您需要使用旧的过时方法,但我真的不建议这样做。这不仅难以管理,而且还意味着,例如,如果您修复了之前已删除的修补程序中的安全错误,则在删除较新的修补修补程序时,安全漏洞未被修补。这是自MSI 3.0以来已经出现的超频的美化。

对于你的问题,虽然我不推荐它。 MSP最好以基线为目标。是的,他们可能会变得更大一些,但前提是您要添加内容。如果更新的版本只是更新文件集或其他资源,则针对单个MSI的MSP不应该比基本MSI更大(因为CAB嵌入MSP并始终应该是MSI +外部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/

虽然这是可能的。在构建每个修补程序时,您需要保存升级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属性定位相同的基准。

1

根据我的经验,通常的做法是在某个时候创建​​一个主要升级MSI(请参阅WiX mainupgrade元素)。这个带有新ProductCode且版本高于上一个补丁版本(例如2.0.0)的MSI将升级1.0.0和1.0.12之间的所有版本。然后你开始基于2.0.0产品进行修补。

修补程序中有多个选项可以替换每个整个文件或通过对每个文件进行二进制修补来修补 - 我不确定您使用的是哪一个,但显然如果您为一个大文件创建一个小补丁,大于补丁是对该文件的二进制更新。