使用WiX Toolset创建.NET程序发布Bootstrapper（安装策略管理）（一）——初识WiX

原文:使用WiX Toolset创建.NET程序发布Bootstrapper（安装策略管理）（一）——初识WiX

Visual Studio 打包安装七宗罪

开发.NET的人，肯定会使用Visual Studio里面自带的MSI打包安装工具框架。如果是在一般情况下，这个打包安装框架已经完全足够满足产品发布安装的需要了。它的制成品，是一个setup.exe，一个MSI安装文件，如果你选择项目以来的其他.NET，Windows Install 框架，并且确定随产品发布，那制成品中还会包含这些东西的安装文件。

但是VS打包发布出来的安装包，安装体验实在是非常差，举个例子，如果你的项目是依赖于.NET 4.0以及VC++ 2010，并且你的目标客户机中没有安装过任何该类产品，那当你执行setup.exe的时候，先是会弹出.NET 4.0客户安装协议，用户点击“同意”后，再弹出VC++ 2010客户安装协议，用户再次点击“同意”，才能开始真正安装。并且在安装过程中，每安装一个东西，如果是在Vista之上的系统上，就会弹出一次需要确认安装并且提升权限的对话框，实在是不胜其烦。

并且这个打包的选项也非常奇怪，如果会使用Installer发布工具的，就会记得里面永远只能在“网上下载所需依赖项”和“本地包含所需依赖项”中二选其一。那如果我想定制发布安装包，如果发现依赖项不存在，再自动去网上下载呢？不好意思，做不到。而且如果我打包出来的MSI是中文的，那发布的时候必定会带上.NET的中文语言包。如果不是修改系统的bootstrapper配置，这个语言包就是必须跟着的，真是完全无厘头，我产品是多语言安装的，难道.NET也要多语言包吗？

必须掌握的一些基础概念

Wix的全称是（Windows Installer XML），简而言之，就是用XML来配置和定制个性化的安装方案。其中一部分称为Burn，是本文接下去要着重介绍的Bootstrapper开发框架，另一部分则为Setup开发框架。

先说一下Bootstrapper和MSI的区别，MSI是微软比较新的一套安装解决方案，依赖于Microsoft Install Service，其实MSI可以理解为一套强格式的安装库，MSI文件中包含了一系列数据结构和文件，数据结构说明了例如要创建哪些目录，要创建哪些注册表项，要拷贝哪些文件到哪些目录中，创建什么快捷方式等配置信息，以及需要拷贝发布的所有文件数据。然后安装服务通过这些配置信息，读取并一步步执行，最终就完成了一个MSI的安装过程。MSI文件就是一个更强大的压缩文件安装包。

问题是如果你的城西使用纯C++开发的，那只要一个MSI发布就解决问题了，因为发布以后不依赖于其他东西可以直接执行。但是既然你用了微软的东西，现在.NET几乎是Windows上必须会涉及的框架，那大多数程序都会依赖于.NET。这时候问题就来了，如果客户机上没有安装.NET，怎么办？你又不能把.NET单独带在你的MSI中一起发布。这个时候就需要在安装MSI之前判断一下系统的安装环境，比如有没有安装.NET，如果已经装了就不用再安装了，当然其他的一些框架也需要判断，这些提前判断的事情MSI是做不了的，当然你的程序也做不了，因为还没有.NET环境啊，你的程序是用.NET写的！这不是鸡生蛋蛋生鸡的问题吗？

这些问题其实微软也想到了，因此他们自己做了一个简单的setup.exe，你看，这个是exe文件，不依赖于任何其他框架，这个exe会先判断系统环境，并且做出需要下载安装其他框架的决定，然后等基础环境搞定了，就可以安装后我们的MSI了。这个exe，就被称为bootstrapper。

WiX Bootstrapper开发教程

以上所说的这些问题，在WiX中都可以得到解决，当然你甚至可以不用VS的打包发布工具，因为之前我们已经知道，WiX可以开发自己的MSI，只是文本对这个不再详述，VS的打包工具制作出MSI，再用WiX的Bootstrapper安装，相得益彰，省时省力，WiX毕竟只能XML编写，还是很麻烦的。

首先，我们在http://wixtoolset.org/releases中下载WiX Toolset安装文件，VS 2010好像最多支持到3.7版本，然后点击中间齿轮的那一行Install进行框架安装。这个工具是支持VS插件的，安装完成后，VS中就会多出一种项目类型“Wix Toolset”，并且选中后我们选择“Bootstrapper Project”，即可创建出新项目，我们在这个项目中进行我们的bootstrapper开发。

创建完成后，就会多出一个Bootstrapper项目，其中有Bundle.wxs文件，这个文件就是打包安装配置文件。所有的XML元素，都可以通过http://wix.sourceforge.net/manual-wix3/schema_index.htm查询，默认代码如下：

<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
	<Bundle Name="Bootstrapper1" Version="1.0.0.0" Manufacturer="" UpgradeCode="5240b0e0-2b53-44c9-9837-05e9a4b63dbc">
		<BootstrapperApplicationRef Id="WixStandardBootstrapperApplication.RtfLicense" />
 
		<Chain>
			<!-- TODO: Define the list of chained packages. -->
			<!-- <MsiPackage SourceFile="path\to\your.msi" /> -->
		</Chain>
	</Bundle>
</Wix>

下面我们来逐个标签元素来看一下这个文件是如何影响运行的

Bundle，这个是所有配置的根节点，其中Name就是我们发布的产品名称，可自定义，注意该名称会出现在安装对话框的标题栏以及卸载程序列表中的名称。Version是版本号，Manufacturer是开发者名称，这些都会出现在卸载程序列表中，UpdateCode是很重要的属性，如果两个产品的UpdateCode一样，那Version更大的产品会自动将小版本程序卸载后再安装，也就是自动的覆盖安装。这些概念都是所有的安装框架通用的。

BootstrapperApplicationRef这个概念比较复杂，按照我使用下来的经验，这个就是使用已经定义完成的安装框架模板，Id="WixStandardBootstrapperApplication.RtfLicense"是一个已经现有的安装框架界面，表示这个Bootstrapper执行后会显示一个客户安装协议对话框，对话框中的文本是可以自定义的。我们会在之后的篇幅中讲到这个元素的详细自定义。

Chain，这个就是表示安装的序列，所有的自定义安装顺序就在这个节点中完成，比如我们可以先定义安装a.exe，再安装b.msi，再安装c.msp等等，都可以在这个节点中进行配置。

我们来编辑一下wxs文件，指定Bundle/@Manufacturer的属性内容，以及为Chain增加一个子节点，Chain节点中必须有一个子节点，我们可以随便生成一个.msi安装文件，然后复制到我们的bootstrapper项目中，然后增加Chain中的子元素Msi，并且生成一下这个工程，最后的wxs文件如下：

<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi" xmlns:bal="http://schemas.microsoft.com/wix/BalExtension">
	<Bundle Name="DemoWixBootstrapper" Version="1.0.0.0" Manufacturer="VanPan" UpgradeCode="5240b0e0-2b53-44c9-9837-05e9a4b63dbc">
    <BootstrapperApplicationRef Id="WixStandardBootstrapperApplication.RtfLicense"/>
		<Chain>
      <MsiPackage SourceFile="Setup1.msi"/>
		</Chain>
	</Bundle>
</Wix>

其中Setup1.msi文件，就是随便拿VS生成的一个Install成品MSI，你也可以使用你自己的项目MSI替换之。生成后，在项目的Debug文件夹内，就会看到有一个Bootstrapper1.exe文件，大小比我们放入的Setup1.msi略大，其实这个就是把MSI打包到安装exe中的结果。双击一下exe，就能看到安装画面了。

我们看到，标题栏就是我们自定义的Bundle/@Name属性内容，你可以自己点击一下Install按钮体验一下安装的效果，当然这个还是一个非常粗糙的样品。请放心，这个框架绝对绝对不会和你想象得那么简单。我们后面的文章再继续详解如何自定义安装序列，自定义安装协议，本地化安装界面，甚至调整安装界面布局。