原文:Wix打包系列 （六）制作升级和补丁包

前面我们已经知道怎么制作一个完整安装包了，但我们的软件往往不能一次性就满足客户的需要，当客户需要我们给软件进行升级的时候，我们应该怎么做呢？

在这之前，我们有必要了解下Windows Installer中的Upgrades定义：

6.1 关于Windows Installer Upgrades

在Windows Installer中将软件产品的更新划分为3类：

• Small updates    它意味着安装包里一个或几个文件的很小的改变，使用Small updates时不需要改变Version属性，也不需要改变Product GUID和UpgradeCode属性。唯一要改变的只有Package GUID，事实上我们每次重新生成安装包都需要改变Package GUI。如果是同一安装包，即Package GUID不改变，你在安装程序后，再点击安装包，会弹出维护的界面（卸载和修复）；如果是Package GUID改变了，则会弹出错误：“已安装了该产品的另一个版本。无法继续安装此版本…”。

注意任何时候重新生成安装包一定要更改Package GUID，使用不同的Package GUID可以方便管理安装的更新包（msp），不同的Package使用相同的GUID会造成安装程序混乱，造成意想不到的后果。那么既然Small updates时更改Package GUID后运行会弹出错误，那么怎么应用Small updates呢？我们可以用命令行方式执行安装程序，或者通过执行Patch更新包（msp）。制作Patch更新包后面会详细讲，我们先看看命令行方式：

msiexec /fvomus [path to updated .msi file] 

或者 

msiexec /I [path to updated msi file] REINSTALL=ALL REINSTALLMODE=vomus. 

• Minor upgrades 在这种情况下，需要更改product version，当然Package GUID也要改变，Product GUID和UpgradeCode属性仍然保持不变。这种方式允许我们添加新的features和components，但是不能改变feature-component树的组织结构。Minor upgrades和Small updates很相似，似乎只是多了个版本变化而已；事实上，可以用Small updates的地方肯定也可以用Minor upgrades，应用Minor upgrades的方式跟应用 Small updates一样，可以使用命令行或者patch方式。
• Major upgrades 在这种情况下，需要更改Version 属性, Product 和 Package GUID，我们仍然保持UpgradeCode属性不变，大家可能会注意到，UpgradeCode在这里似乎没什么用处，先别急，下面我们会马上讲到它的用处。先看看Major upgrades ，事实上，对开发人员来说，它是一个最安全和最便捷的升级方式，因为Product GUID已经改变，意味着它可以和老版本共存安装到一台计算机上，并且是一个完全的全新安装。

关于Product/@Id属性（GUID），Product/@Version属性，Product/@UpgradeCode属性（GUID），还有Package/@Id属性（GUID）；这几个属性在第一章有提到过，在这里我们就可以更清楚他们的意义了

6.2 检测并替换现有版本（Major upgrades）

讲到这里，大家应该对Windows Installer制作升级的基础知识有了一定的了解。但是如果我们的安装包体积不大，希望使用Major upgrades，但是又不想每次安装新版本时要手动卸载以前的版本，要怎么做呢？

最好是方式是让安装程序能检测以前版本，然后删除以前版本，最后安装新版本程序；要想能检测到以前版本的信息，这时UpgradeCode就起到作用了。当我们制作更新包或升级版本时，首要要确保我们有以前老的版本的安装包；另外就算我们不打算当前版本被升级，也必须包含UpgradeCode属性，因为一旦你没提供UpgradeCode属性，以后就没有办法再提供了；我们还应该知道什么时候应该改变UpgradeCode属性，事实上，我们在开发一个项目时，可以一直保持UpgradeCode不变，即使Product GUID已经改变，当然你也可以改变UpgradeCode以更好的管理程序版本。

要解决我们的问题还需要引入UpgradeVersion标签，它能帮助我们检测已安装的版本信息和将要升级的版本信息。

<Upgrade Id="F4F8195E-E907-42dd-BB90-CC2403FA7384">

    <UpgradeVersion OnlyDetect="no" Property="PREVIOUSFOUND" 

        Minimum="1.0.0" IncludeMinimum="yes" 

        Maximum="$(var.Version)" IncludeMaximum="no" />

    <UpgradeVersion OnlyDetect="yes" Property="NEWERFOUND" 

        Minimum="$(var.Version)" IncludeMinimum="no" />

</Upgrade>

    Upgrade的Id属性是我们安装的以前版本的UpgradeCode，如果你的程序应用了多个UpgradeCode，那么你只需要添加一个新的Upgrade标记就可以了，每个Upgrade标记包含自己的版本范围。我们可以看出来，要想更好的管理版本，我们不应该频繁更换UpgradeCode，不然这里就要写很多个Upgrade标记了，对应还要写很多custom action；我们最多在每个大版本的时候更换UpgradeCode就足够了，比如1.x版本时使用一个UpgradeCode，2.x时使用另外一个UpgradeCode；当然你也可以选择不更换UpgradeCode。

    Minimum 和 Maximum指定Upgrade中我们应该升级的版本范围，IncludeMaximum 和 IncludeMinimum 指定升级范围是否包含边界值（IncludeMinimum='no' 表示只查找以上版本）。

使用Upgrade 标记后将会触发一个新的标准动作FindRelatedProducts，它在LaunchConditions动作后执行，当然我们可以在InstallExecuteSequence中重定义它的执行顺序，但一般情况下我们不用这么做。FindRelatedProducts动作 通过Upgrade 标记检查其中的所有版本，如果找到了，则它的Product GUID将会被追加到UpgradeVersion标记中指定的Property中（如示例中的PREVIOUSFOUND和NEWERFOUND）；这里的UpgradeVersion的Property属性，相当于定义了2个Property：PREVIOUSFOUND和NEWERFOUND。

OnlyDetect='yes' 告诉我们安装程序不会移除以前的程序吗，如果我们是Major upgrades ，将OnlyDetect置为no，则会删除以前版本的程序，从而可以保证目标计算机中只有一个版本的product；如果是Minor upgrades ，我们需要将OnlyDetect置为yes。

如果开发一个本地化的软件包，你也可以在UpgradeVersion 中指定Language属性。

注意在这里我定义了2个UpgradeVersion，他们的Property属性分别是PREVIOUSFOUND和NEWERFOUND。PREVIOUSFOUND是查找以前安装的版本，最低版本是1.0.0，它是始终不变的；最大版本是当前版本，需要在编译的传进来，这样做的目的是每次改变版本不用去修改源代码中的版本号；OnlyDetect置为no表示会删除掉找到的安装程序版本。比如当前版本是3.0.2，则在安装当前版本过程中，在版本1.0.0和3.0.2之间的任何版本都会被删除，包括修订版本。移除以前版本完全是自动的，如果我们要在移除以前版本前做任何事情，我们可以写一个custom action，设置它的condition为UPGRADINGPRODUCTCODE 属性的值。Windows Installer只是在自动删除的进程里才会设置这个属性，在添加/删除程序里手动删除程序不会设置该属性的值。

那么为什么要设置NEWERFOUND呢，试想如果你已经安装了2.0版本的程序，然后又安装1.0的版本的程序，一般情况下安装会正常进行，安装程序不能自动删除新版本的程序，这时候我们检测到新版本程序后就需要弹出错误提示，提示用户已安装更新的版本。如何做到这点呢，我们需要添加一个custom action，以下代码在FindRelatedProducts后如果找到新版本，则会执行NoDowngrade 的custom action，该action会弹出一个错误提示，阻止安装程序继续运行。

<CustomAction Id='NoDowngrade' Error='已经安装了较新版本的 [ProductName]，无法继续安装该版本应用程序 .' />

 <InstallExecuteSequence>
     <Custom Action='NoDowngrade' After='FindRelatedProducts'>NEWERFOUND</Custom>
 </InstallExecuteSequence>

candle.exe -dVersion=1.0.0  -ext WixUtilExtension -ext WixSqlExtension Sample.wxs DbConfigDlg.wxs -out 1.0.0/
light.exe -loc WixUI_zh-cn.wxl  -ext WixUIExtension -ext WixUtilExtension -ext WixSqlExtension -out 1.0.0/Sample.msi 1.0.0/Sample.wixobj 1.0.0/DbConfigDlg.wixobj 

candle.exe -dVersion=1.0.1  -ext WixUtilExtension -ext WixSqlExtension Sample.wxs DbConfigDlg.wxs -out 1.0.1/
light.exe -loc WixUI_zh-cn.wxl  -ext WixUIExtension -ext WixUtilExtension -ext WixSqlExtension -out 1.0.1/Sample.msi 1.0.1/Sample.wixobj 1.0.1/DbConfigDlg.wixobj 

<?xml version='1.0' encoding='utf-8'?>
<Wix xmlns='http://schemas.microsoft.com/wix/2006/wi'>
    <Patch AllowRemoval='yes' Manufacturer='Acme Ltd.' MoreInfoURL='www.acmefoobar.com' 
           DisplayName='Police1.0.1.0 Patch' Description='Minor Update Patch' Classification='Update'>
        <Media Id='5000' Cabinet='SamplePatch.cab'>
            <PatchBaseline Id='SamplePatch' />
        </Media>
        <PatchFamily Id='SamplePatchFamily' Version='1.0.0.0' Supersede='yes'>
            <ComponentRef Id='compMainExecutable'/>
            <ComponentRef Id='compManual'/>
        </PatchFamily>
    </Patch>
</Wix>

torch.exe -p -xi 1.0.0/Sample.wixpdb 1.0.1/Sample.wixpdb -out Patch.wixmst

candle.exe Patch.wxs
light.exe Patch.wixobj

pyro.exe Patch.wixmsp -out Patch.msp -t SamplePatch Patch.wixmst

msiexec /p Patch.msp