Wix打包系列 (六)制作升级和补丁包

  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>
    6.3 制作升级补丁(Minor upgrades And Small updates)

 
    到这里大家应该知道为什么我说Major upgrades 是最安全的,因为不管你之前安装的是什么版本,都会删除掉然后安装当前版本。而对于Minor upgrades,你需要针对每个不同版本安装包制作Patch更新包(msp),比如从1.1.0到1.1.1,从1.1.1到1.1.2,如果想从1.1.0到1.1.2,则需要重新制作Patch更新包(msp),当然也不是不可以制作通用于所有版本的Patch更新包(msp),前提是你要有所有版本安装包(msi),制作方法相对也比较繁琐,而且Minor upgrades还有诸多限制,如果处理不好会导致安装错误。当然如果你的安装文件体积太大,使用Major upgrades 就不合适了,一般情况下我们使用Minor upgrades ,下面我们就看看如何为Minor upgrades 制作Patch更新包(msp)。

    制作制作Patch更新包之前,需要注意以下情形:

•当你需要新老版本共存时,则必须使用Major upgrades。
•当你需要更改生成的msi文件名称的时候,不能使用Minor upgrades或Small updates
•当你更改了Packge里任何Component的GUID时,不能使用Minor upgrades或Small updates
•当有组件被移除时,不能使用Minor upgrades或Small updates
•当更改了Feature的组织结构,比如在Feature中添加或删除子Feature时,不能使用Minor upgrades或Small updates
    如果新版本满足这些条件,我们就可以开始制作更新包了,  这里我们将在新版本(1.0.1)安装中添加一个dll文件,然后更改exe执行文件。制作步骤如下:

    1、编译生成1.0.0版本安装文件

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   

    2、 接着把1.0.0文件夹的内容复制到新的文件夹1.0.1中,用记事本随意修改FoobarAppl10.exe文件和Manual.pdf文件,以区别于1.0.0版本; 

   3、编译生成1.0.1版本安装文件

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    4、创建wix源文件Patch.wxs,内容如下:
<?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>    Classification属性可以是: Hotfix, Security Rollup, Critical Update, Update, Service Pack or Update Rollup。AllowRemoval 属性确定用户在以后是否能够卸载该补丁包。

    PatchFamily 标记包含要被修补的项目,Supersede决定是否目前的补丁包替换掉相同的系列里的所有以前的补丁包。PatchFamily 的子元素可以是ComponentRef或者FeatureRef等是对Sample.wxs文件中的元素引用,表示版本间不同的地方

    5、使用另外一个wix工具torch在两个安装包之间来创建一个transform文件。命令行参数-xi指示程序使用wix自己的格式.wixpdb 和.wixmst,而不是Windows Installer格式 (.msi and .mst)。

torch.exe -p -xi 1.0.0/Sample.wixpdb 1.0.1/Sample.wixpdb -out Patch.wixmst    注意执行torch命令所在文件夹不能包含中文,否则执行会出现文件不存在的错误
    6、使用wix编译器和连接器生成补丁包,但是这次输出格式跟往常不一样,是.wixmsp格式的。在这里不需要告诉linker生成这种类型的文件,linker将根据源文件的内容自动决定生成什么格式的文件。
candle.exe Patch.wxslight.exe Patch.wixobj      
    7、最后,我们用上一步生成的wixmsp文件和刚才生成的transform文件来创建目前的Windows Installer 补丁包。Pyro是负责生成补丁包的wix工具,它不仅需要transform文件名,还需要相应的PatchBaseline/@Id属性,最好是用命令行模式:
pyro.exe Patch.wixmsp -out Patch.msp -t SamplePatch Patch.wixmst生成的patch.msp就是修补安装程序,为了测试它,我们先安装原始安装包(Error/Product.msi),然后添加修补程序:

msiexec /p Patch.msp检查文件是否真的被更新成新版本了。接着到添加/删除程序,选择显示更新,并移除第一个补丁,所做的更改将恢复到更新前的状态。

    这里介绍的只是1对1版本的升级,也可以同时为多个不同的旧版本制作最终版本的升级包,有兴趣的可以参考sdk文档。下一章我们将介绍如何添加系统必备组件的安装程序。

 

本文来自CSDN博客,转载请标明出处:http://blog.csdn.net/duanzilin/archive/2010/10/29/5974488.aspx

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值