转载fromVan Pan 的专栏
http://blog.csdn.net/rryqsh/article/details/8274832
http://blog.csdn.net/rryqsh/article/details/8277585
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查询,默认代码如下:
下面我们来逐个标签元素来看一下这个文件是如何影响运行的
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文件如下:
其中Setup1.msi文件,就是随便拿VS生成的一个Install成品MSI,你也可以使用你自己的项目MSI替换之。生成后,在项目的Debug 文件夹内,就会看到有一个Bootstrapper1.exe文件,大小比我们放入的Setup1.msi略大,其实这个就是把MSI打包到安装exe中 的结果。双击一下exe,就能看到安装画面了。
我们看到,标题栏就是我们自定义的Bundle/@Name属性内容,你可以自己点击一下Install按钮体验一下安装的效果,当然这个还是一个非常粗糙的样品。请放心,这个框架绝对绝对不会和你想象得那么简单。我们后面的文章再继续详解如何自定义安装序列,自定义安装协议,本地化安装界面,甚至调整安装界面布局。zhuan
自定义产品卸载方式
继续从上一次的基础上前进,现在我们已经知道了最简单的bootstrapper打包方法,现在我们对其中的每个节点深入自定义,争取可以达到我们需要的效果。先把最后全部的XML贴出来。
Bundle节点前面几个属性我们都已经知道了,IconSourceFile就是打包后exe的图标设置,DisableRemove、 DisableModify这两个属性比较有讲究,他们分别设置了在“添加/删除程序”列表中,选中安装包后鼠标右击,是否会出现“卸载”和“修改”这两 个选项。如果这两个选项都同时为yes,那这个产品安装后根本就不会出现在“添加/删除程序”列表中,只能通过再次双击bootstrapper安装 exe进行卸载。
自定义产品安装界面
BootstrapperApplicationRef这个节点上一篇已经讲解过,但是我们使用的是最原始的默认界面,事实上可以通过在该节点中加入 WixStandardBootstrapperApplication来自定义安装界面。LicenseFile就是要显示在用户安装协议中的RTF文 件名称。ThemeFile是自定义主题xml文件,该文件详细定义了安装界面中的每个按钮和控件的位置。LocalizationFile是本地化配置 文件,这个版本的Burn框架还不支持运行时自动根据安装语言环境自动切换。如果你需要采用本地化安装策略,比较靠谱的方法就是在 bootstrapper之前再执行另一个exe,用来判断语言环境并自动执行不同的bootstrapper进行安装。LogoFile是安装界面左上 角那个图标,注意XP环境下好像是不能使用ICON文件的。
ThemeFile="MyTheme.xml" 这个文件可以在WiX源代码中找到,我贴在这篇博客里面,方便大家直接复制粘贴,这文件和后面的本地化文件的确不好找。
自定义安装序列
上面我们已经将安装界面全部自定义完毕,脸面上的事情总算是做完了,我们要解决的根本问题还在眼前,如何自定义调整安装顺序?答案就是通过Chain节点 来完成。Chain节点定义了打包安装的顺序,默认是从上到下逐个完成,当然你也可以在子节点中通过After属性来调整安装顺序。
首先是判断并安装.NET Framework 4.0环境。
Compressed表示是否要将该安装包打包在bootstrapper.exe文件中,我们回忆一下上一讲,上一讲我们的Setup1.msi文件因 为没有带上该属性,就自动将安装包打包在bootstrapper中了,因此我们只得到了一个安装文件。如果Compressed="no",那就会在bootstrapper.exe边上出现另外一个单独的安装文件,这样可以减小我们发布的尺寸。
PerMachine是表示是否要采用UAC权限进行安装,因为有些安装文件需要以管理员身份运行才能安装成功,而我们现在采取的是静默安装策略,因此需要在定义安装的时候就表明是否需要UAC权限。
Permanent表示卸载时是否需要同时卸载该安装包。yes表示卸载产品时该安装包不需要同时卸载,将会永远留在客户的计算机里面。
Vital表示是否该安装时必须的,如果该安装是必须的,那如果该安装没有成功,后续的所有安装都不会进行。
InstallCommand是在安装时需要跟上的参数,我们知道.NET的静默安装需要带上“ /q /norestart”参数,这样我们用bootstrapper托管下就可以让.NET静默安装完毕了。
SourceFile表明安装文件的名称是什么,它和DownloadUrl是任选的,也就是说如果安装时发现该文件包不存在的话,需要从什么URL进行自动下载并安装。
DetectCondition是bootstrapper的精髓,它用一个表达式来判断一台计算机上该包是否已经安装 过,DotNetFramework40FullInstallRegValue和文档最后的util:RegistrySearch节点ID是一致的,util:RegistrySearch代表查看注册表中的某个表项的值的变量,然后匹配该注册表项值满足条件,则说明已经安装,如果不满足则说明需要安装。
完成上面的这些工作,再把所需要的安装包,配置文件都放到工程里面后,经过项目生成,我们就拿到很完美的bootstrapper了。现在的结果是,最极 限情况下我们只需要发布一个bootstrapper,后续所有的软件依赖就能下载并安装,极大得减少了用户下载安装的负担。并且因为可以动态判断依赖 包,所以用户的安装速度也得到极大的提升。最最重要的是,只需要在安装第一个包的时候进行一次UAC询问,后续就不再会有类似的恼人确认对话框了。至此, 我们之前所有提出的VS打包项目的不足就全部解决了。