Windows Installer和WiX的创建

Question

我们目前使用WiX来构建我们的MSI文件,因此它是我使用过的唯一一个MSI构建器.我知道您可以在Visual Studio中本地构建安装程序.使用WiX和Windows Installer有什么区别,各自的优缺点是什么？

Answer 1

我只是想在Windows Installer技术本身上添加一些更具体的技术信息,以及导致WiX工具包创建的一些历史,因为这篇文章可能是刚刚进入安装人员领域的人们所发现的,WiX和Windows Installer.

这是从开发人员的角度快速介绍WiX和MSI.还有一篇有点受欢迎的serverfault.com文章,可能有助于掌握Windows Installer的好处:使用MSI文件的公司优势(许多开发人员不喜欢Windows Installer,但企业部署的好处实际上非常重要 - 如果快速浏览,可能值得快速浏览一下你认为MSI比它的价值更麻烦.

WiX工具包的起源

MSI文件本质上是剥离存储为COM结构化存储文件的SQL Server数据库.这是Microsoft Office中使用的文件格式(请注意,MS Office以前使用的是OLE/COM文件 - 但是较新的版本现在使用Office Open XML),它被设计为在单个文件中存储分层数据的方法.本质上是文件中的文件系统,具有各种类型的存储流 - 其中一个是要安装在一个或多个cab文件中的文件.

早期的MSI文件/数据库最好使用第三方工具直接修改,如InstallShield,Advanced Installer和明智的套餐工作室(由于法律问题而不再可用 - 请参阅当前可用的MSI工具的比较).这些工具将MSI文件以其本机"可安装"格式存储为COM结构化存储文件.这意味着您的MSI文件既是源文件又是可执行文件 - 并且采用二进制格式.这使您的安装项目的源代码控制变得困难.不同MSI数据库上的二进制差异是困难的,并且由于数据库参考完整性,即使MSI中的最基本的变化将级联通过几十个表,并且使得即使对于受过训练的眼睛也难以看到改变的情况.

WiX作为开发人员允许从常规文本源文件创建二进制MSI文件的一种方式出现.就像常规的EXE二进制文件一样,MSI二进制文件是从WiX文本XML文件中"编译"的.在管理发布过程和理解MSI文件中的更改方面,这是一个巨大的飞跃.该工具包非常全面,对开发人员来说更直观,并具有一定程度的"自动化",因为它可以保护开发人员免受MSI数据库模式的某些复杂性的影响,因为更改是以XML格式进行的,具有自己的模式而不是数据库本身.实际上,WiX将MSI从其数据库起源转移到今天的"XML时代",以便开发人员使用文本文件,并且可以将MSI文件视为已编译的可执行文件而不是数据库源文件.

实际上,可以制作好的MSI文件,而不必过多了解MSI文件的内部工作原理 - 只要您遵循WiX最佳实践 - 并相信我作为开发人员,您将不想使用MSI文件.它们是复杂的,并且对于开发者的心态来说是非常不正统和违反直觉的.它与将整个安装程序存储为单个数据库的复杂性有关.它几乎完全是声明性的而不是程序性的 - 但有些部分是顺序的并且定义了安装顺序.大量的活动部件和" 吸气复杂性 " 的发条(你发现你认为一切都很好的陷阱).

这些排序构造是MSI中一些最复杂的部分,涉及" 提升权限 ",文件系统操作作为数据库事务运行.当您作为开发人员学习MSI时,您一定会觉得"这个设计出了问题",而事实是整个技术是围绕Office的部署要求设计的 - 它变得如此复杂.必须是.此外,MSI文件可能是未来的预览 - 也许Windows将来会使用SQL Server作为其主要的存储解决方案,而MSI是将部署转换为"声明性语言"或巨大的SQL语句的第一步.在部署期间会在目标系统上发生吗？这只是猜测.

一些实用的WiX建议

保持简单,遵循最佳实践,无论你做什么都不打击设计 - 它反击.如果WiX无法做到这一点,它可能会试图帮助您避免部署问题.打击你的经理简化或改变要求,而不是MSI - 一旦它更容易:-).

大多数情况下,我们发现不寻常的设置设计和自定义操作的使用会导致很多不必要的复杂性,或者如果您愿意,可以部署反模式,并且通常可以通过应用程序设计中的微小更改或使用内置的MSI结构.一个好的经理将允许努力简化部署,但他们需要理解为什么有必要.我喜欢许可作为一个例子,说明如何以不同的方式做事,并通过避免过时的或不必要的,复杂的应用程序和部署解决方案来简化部署.

不惜一切代价避免不必要的(读/写)自定义操作 - 它们会降低设置的复杂性和风险.在这里询问Stack Overflow并搜索是否有内置替代方案.在大多数情况下或者至少在很多情况下,MSI中都有相同的内置构造来完成工作.

这个特别的建议不容小觑.在我个人看来,只读自定义操作(可能设置属性)是相反的:建议使用它们.在大多数情况下,它们不会造成显着的额外风险 - 因为它们不需要对需要回滚支持的系统进行任何更改,并且可以非常有效地用于在一个地方收集设置逻辑 - 并且至关重要的是它们在同事之间很好地工作以允许拾取用简单的脚本语言编写时,彼此的工作JavaScript的(处理MSI API时有些笨拙的方面)或VBScript(错误处理和整体语言功能不佳,但使用MSI API进行了充分测试.坦率地说,似乎微软试图"杀死"该语言.JavaScript至少是"活着"并且"很好地用于网络东西".

总结关于脚本的事情:部署专家普遍认为,所有类型的脚本操作通常难以调试,容易受到反病毒干扰,并且缺乏实现高级编码结构所需的语言功能.总之:用任何类型的脚本编写健壮的代码是很困难的.托管代码自定义操作是可能的(.NET),但由于需要安装.NET,因此安全建议使用C++编写自定义操作.这允许最小的依赖性,非常好的调试和高级语言结构.这里对这个问题进行了长时间的"讨论":不同自定义动作类型的优缺点(不是很好,只是转移现实世界的经验).虽然可能值得一试 - 自定义操作是导致部署失败的主要原因(链接到我对他们的宣传),这将我们带到下一点:部署的整体复杂性(以及如何处理它).

部署的复杂性

部署是将异构目标计算机从一个稳定状态迁移到另一个稳定状态的复杂过程 - 这需要一种规范的方法,因为:

1. 错误本质上是累积性的 - 您通常会通过快速修复来解决问题,从而导致更多问题.很快你就不可能保持在你的手上,因为问题通常是"在野外"(已发布)并且必须像交付过程一样处理 - 每次迭代都有自己的,增加的风险,而不仅仅是一个问题调试,直到你有一个修复程序.
2. 当您无法访问相关系统时,错误很难调试.记录可以在正确完成时提供帮助,但是当您需要它进行调试时,它通常不会提供给您,或者它的格式或冗长是错误的,或者完全无用,因为自定义操作通常不会正确记录事件.
3. 目标系统(和目标环境)在几乎所有可想象的方式上都有所不同(即使是大多数公司使用标准操作系统安装和软件包的标准操作环境(SOE)):硬件和驱动程序的差异(大和小),胖客户端/瘦客户端,终端服务器,操作系统平台(x86/x64 /等...),操作系统版本(Win7,Win10,WinXP等等),操作系统版(终极版,家用等). .),操作系统语言版本,操作系统升级状态和补丁级别,恶意软件情况,磁盘空间问题,分区方案,文件系统类型,加密问题(文件系统,网络),用户权限设置,UAC配置,系统权限配置(NTRights) ,连接类型,连接速度,网络配置(域,工作组等),子网,代理设置,电子邮件系统和配置(Exchange,Outlook,Novell等...),活动目录,身份验证方案,网络共享和驱动器,应用程序空间,脚本可用性,脚本锁定 n,各种运行时版本(C,C++,MFC,ATL,ADO,OLE DB,ADO.NET,Java,脚本运行时),COM和DCOM对象注册和配置,COM +,IIS和Web服务器,路径变量和环境变量,文件关联和shell操作,无线软件设置,用户数,.NET版本和配置,语言包,GAC和WinSxS状态和配置(策略文件),软件防火墙,模拟/虚拟化系统,部署系统(SCCM,Tivoli等等......)它会一直持续下去.

部署是一个简单的概念,具有复杂的变量组合,可能导致最神秘的错误 - 包括开发人员最喜欢的:间歇性错误.众所周知,这些错误的严重性不容小觑,因为它们通常无法正常调试.

有关部署以及现代安装程序可能需要做什么的更多信息:程序安装的好处和真正目的是什么？.这是一个概述,可以要求设置完成各种技术细节.可能添加了太多细节,可能会破坏答案的"概述质量".然而,目的是保持与开发人员的相关性.

相关的MSI工具

Visual Studio MSI项目文件是一种轻量级的方法,可以在Visual Studio中创建MSI文件,并且其功能集非常有限.有人谈论将Visual Studio中的MSI项目类型替换为WiX XML项目,这通常是人们现在如何构建他们的MSI文件.不要使用此项目类型.由于缺乏灵活性和严重的错误,它给许多用户带来了严重的问题.

Orca是 Windows SDK工具,它允许打开,编辑二维MSI文件并在一定程度上进行比较.事实上,它主要是由后来创建WiX工具包的人编写的.当他在微软的 Windows Installer团队工作时, Rob Mensching.该工具还允许其他操作,例如生成用于修改MSI文件的转换文件和一些其他技术操作.虽然它是一个非常基本的工具,缺乏商业工具中可用的最高级功能,但它仍然是应用程序包装者最喜欢使用的,并且由于其可靠性,简单性和"清洁度 "而可用于调试和小修复 - 它不添加"默认垃圾"保存时到MSI(第三方工具添加自定义表和类似的垃圾).我将它用于小型MSI更新,调试,检查摘要流,创建基本转换,查看补丁,包验证和其他重要操作.

事实上,我猜这是一个高级工具,具有简单的界面 - 而不是基本工具:-).为了掌握Orca,您需要安装Windows SDK(!).当工具的尺寸如此之小时,真的有点超过顶部,但至少很容易知道它可用的地方而不是寻找单独的下载.

更新:如果您安装了Visual Studio并安装了SDK Orca-x86_en-us.msi,请搜索并安装它.如果你不这样做,可能有一个安装了Visual Studio的朋友搜索它然后发送给你？这是一个小文件.

还有一些替代的免费工具,如此处所述(底部):如何比较两个(或更多)MSI文件的内容？

DTF - Deployment Tools Foundation是一套.NET类,用于以编程方式处理MSI文件.写得好,易于使用且功能非常强大,现在包含在主WiX下载中.它是自动化企业使用 MSI文件的任何项目中的关键组件.以下是serverfault.com上关于其使用和描述其基本组件的简要回答.DTF附带的帮助文件将使您快速使用该工具包,并且您将永远不会回头使用Win32函数或COM类来访问MSI文件.

市场上还有许多其他Windows Installer工具,其中一些可以找到与WiX相比在什么样的安装产品上使用？InstallShield,WiX,Wise,Advanced Installer等(与上面相同的链接).

Answer 2

WiX创建使用Windows Installer的MSI包.所以WiX使用Windows Installer引擎.

Visual Studio只是一种WiX替代方案,只是另一种设置创作工具.我不推荐它,因为它非常有限.它仅提供基本功能.

如果您对WiX感到满意,请继续使用它.