Wix使用笔记 (六)制作升级和补丁包

Wix使用笔记 (六)制作升级和补丁包
2010年10月29日
　　前面我们已经知道怎么制作一个完整安装包了，但我们的软件往往不能一次性就满足客户的需要，当客户需要我们给软件进行升级的时候，我们应该怎么做呢？
　　在这之前，我们有必要了解下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更新包后面会详细讲，我们先看看命令行方式： 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属性是我们安装的以前版本的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会弹出一个错误提示，阻止安装程序继续运行。     到这里大家应该知道为什么我说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版本安装文件     2、 接着把1.0.0文件夹的内容复制到新的文件夹1.0.1中，用记事本随意修改FoobarAppl10.exe文件和Manual.pdf文件，以区别于1.0.0版本；  
　　3、编译生成1.0.1版本安装文件 
　　
　　
　　
　　
　　
　　
　　
　　
　　
　　
　　
　　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将根据源文件的内容自动决定生成什么格式的文件。