Windows Installer和WiX的创建

Question

Windows Installer和WiX的创建

26

我们目前使用WiX来构建MSI文件，因此这是我唯一拥有使用经验的MSI构建工具。不过我知道你可以在Visual Studio中本地构建安装程序。使用WiX和Windows Installer之间有什么区别？它们各自的优缺点是什么呢？

- codewario

1

WiX 有一个学习曲线，但比其他部署解决方案拥有更多的功能。它是免费、开源和非常稳定的。我认为 WiX 不支持商业工具支持的唯一重要事项是应用程序虚拟化，但我现在不确定 - 我可能已经过时了。您可以在此处查看不同工具的优缺点。 - Stein Åsmul

1

我的更新的“建议” - 虽然没有被要求 ;-) - 是，一旦大型公司内部开发团队设置和理解了WiX，它就非常出色。灵活性很高，如果需要，您可以自己修复框架中的错误。而且至关重要的是：团队中有多余的专业知识和/或可以及时培训 - WiX很“棘手”。这在较小的公司甚至只有一个部署人员的大型开发公司中通常不是这种情况。商业工具在这里可能更好。所有部署工具都有许多功能 - 请参见上面的链接进行审查。 - Stein Åsmul

2个回答

18

WiX创建使用Windows Installer的MSI包。因此，WiX使用Windows Installer引擎。

Visual Studio只是WiX的替代品，另一种安装程序制作工具。我不建议使用它，因为其功能极为有限，仅提供基本功能。

如果您对WiX感到满意，请继续使用它。

- rmrrm

2

此外，Visual Studio 2012已不再配备安装项目。只有安装了InstallShield产品的链接（免费版但功能受限）可用。 - Steve B

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Stein Åsmul · Accepted Answer

我想在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和~~Wise Package Studio~~（由于法律问题不再提供 - 请参见当前可用的MSI工具比较）。这些工具将MSI文件存储在其本机“可安装”格式中，作为COM结构化存储文件。这意味着您的MSI文件既是源代码又是可执行文件 - 并且以二进制格式存储。这使得安装项目的源代码控制变得困难。不同MSI数据库之间的二进制差异很难处理，并且由于数据库引用完整性，即使对于经过培训的人来说，MSI中最基本的更改也会影响数十个表格，使得难以看清楚发生了什么变化。

WiX是一种开发者可以使用的工具，允许从常规文本源文件创建二进制MSI文件。与常规的EXE二进制文件一样，MSI二进制文件是从WiX文本XML文件“编译”而来的。这是在管理发布过程和理解MSI文件中更改方面的一个巨大飞跃。该工具包非常全面，对于开发者来说更加直观，并且具有一定的“自动化”功能，因为它将开发者从MSI数据库模式的某些细节中解放出来，因为更改是以XML格式进行的，具有自己的模式，而不是数据库本身。实际上，WiX将MSI从其数据库起源带入了今天的“XML时代”，使开发者使用文本文件，并且可以将MSI文件视为已编译的可执行文件，而不是数据库源文件。 只要遵循WiX的最佳实践，即使不了解MSI文件的内部工作原理，也可以制作出良好的MSI文件 - 相信我作为开发人员，您会希望远离MSI文件。它们很复杂，对于开发人员来说非常不正统和反直觉。这与将整个安装程序存储为单个数据库的复杂性有关。它几乎完全是声明性的而不是过程性的 - 但某些部分是顺序的并定义了安装顺序。有许多移动部件和一个“阴谋性复杂度”的时钟机构（当您认为一切都很好时发现的陷阱）。

这些序列化构造是MSI中最复杂的部分之一，涉及到“提升权限”和作为“数据库事务”运行的文件系统操作。当你作为开发者学习MSI时，你可能会感觉到“这种设计有问题”，而事实上整个技术是围绕Office在过去的部署需求而设计的，因此变得如此复杂。此外，MSI文件可能是未来的趋势 - 也许Windows将来会使用SQL Server作为其主要存储解决方案，而MSI是将部署转变为“声明性语言”或针对目标系统在部署期间要发生的巨大SQL语句的第一步？这只是猜测。

一些实用的WiX建议

保持简单，遵循最佳实践，不要与设计作斗争 - 它会反击。如果WiX无法完成某项任务，那么它很可能正试图帮助您避免部署问题。为了简化或更改要求，请与您的经理进行沟通，而不是与MSI作斗争 - 这次做起来更容易 :-）。

大多数时候，我们发现不寻常的设置设计和使用自定义操作会导致很多不必要的复杂性，或者说是部署反模式。这个问题通常可以通过应用程序设计的微小变化或使用内置的MSI构造来避免。一个好的经理会允许简化部署的努力，但他们需要理解为什么这是必要的。我喜欢licensing作为一个例子，说明如何通过避免老式或不必要的复杂应用程序和部署解决方案来改变做事方式并简化部署。

尽一切可能避免不必要的（读/写）自定义操作——它们会使设置的复杂度和风险增加四倍。在Stack Overflow上提问并搜索是否有内置的替代方法。在大多数或至少许多情况下，MSI中有等效的内置构造可完成任务。

这是一条非常重要的建议。在我个人看来，只读自定义操作（可能设置属性）则相反：它们是被推荐的。在大多数情况下，它们不会带来额外的重大风险——因为它们不会对需要回滚支持的系统进行任何更改，并且可以非常有效地将安装逻辑聚集在一个地方——在简单的脚本语言中编写时，它们非常适合协同工作，比如~~JavaScript~~（处理MSI API时有些笨拙）、VBScript（错误处理和整体语言特性较差，但在MSI API方面经过了良好的测试。老实说，微软似乎正在试图“杀死”这种语言。JavaScript至少在Web开发中得到了广泛应用）。

关于脚本方面的总结：部署专家普遍认为，所有类型的脚本操作通常都很难调试，易受到反病毒软件的干扰，并且缺乏实现高级编码结构所需的语言功能。总之：使用脚本编写强壮的代码很困难 - 无论是哪种类型。 可以使用托管代码自定义操作（.NET），但由于它们需要安装.NET，因此建议安全的做法是使用C++编写自定义操作。这样可以最小化依赖项，非常好的调试和高级语言结构。这里有一个长时间的“讨论”：不同自定义操作类型的利弊（不太好，只是真实经验的转储）。虽然可能值得一读 - 自定义操作是部署失败的主要原因（链接到我反对它们的宣传），这就带我们来到了下一个问题：部署的整体复杂性（以及如何处理它）。

部署的复杂性

部署是将异构目标计算机从一个稳定状态迁移到另一个稳定状态的复杂过程 - 这需要有纪律的方法，因为：

错误是累积性的——你试图用快速修复来解决问题，往往会导致更多问题。很快你就会发现难以维护，因为问题通常已经“在野”（发布），必须像交付过程一样处理——每个迭代都有自己的风险，并不仅仅是一个需要调试的问题，直到你找到解决方案。
当你无法访问所涉及的系统时，错误非常难以调试。记录日志可以帮助调试，但通常在你需要它进行调试时却没有提供给你，或者格式或详细程度不正确，或者完全无用，因为自定义操作通常不能正确记录事物。
目标系统（和目标环境）在各种方面都存在差异（即使它是标准操作环境（SOE），因为大多数公司使用标准化的操作系统安装和软件包）：硬件和驱动程序的差异（大大小小），瘦客户端/胖客户端，终端服务器，操作系统平台（x86/x64等），操作系统版本（Win7、Win10、WinXP等），操作系统版本（旗舰版、家庭版等），操作系统语言版本，操作系统升级状态和补丁级别，恶意软件情况，磁盘空间问题，分区方案，文件系统类型，加密问题（文件系统、网络），用户权限设置，UAC配置，系统特权配置（NTRights），连接类型，连接速度，网络配置（域、工作组等），子网划分，代理设置，电子邮件系统和配置（Exchange、Outlook、Novell等），活动目录，身份验证方案，网络共享和驱动器，应用程序状态，脚本可用性，脚本锁定，各种运行时版本（C、C++、MFC、ATL、ADO、OLE DB、ADO.NET、Java、脚本运行时），COM和DCOM对象注册和配置，COM+，IIS和Web服务器，路径变量和环境变量，文件关联和Shell操作，无线软件设置，用户数量，.NET版本和配置，语言包，GAC和WinSxS状态和配置（策略文件），软件防火墙，模拟/虚拟化系统，部署系统（SCCM、Tivoli等）。这个列表还可以继续下去。

Deployment是一个简单的概念，但是由于各种变量的复杂混合，可能会导致最神秘的错误 - 包括开发者喜欢的间歇性错误。正如我们所知道的那样，这些错误的严重性不言而喻，因为它们通常无法得到适当的调试。

更多关于部署的内容以及现代设置程序可能需要执行的操作：程序安装的好处和真正目的是什么？。这是一个摘要，列出了设置可能需要执行的任务，并夹杂着各种技术细节。可能添加了太多细节，也许破坏了答案的“概览质量”。然而，意图是保持与开发人员相关。

Windows Installer和WiX的创建

WiX工具包的起源

一些实用的WiX建议

部署的复杂性

相关的MSI工具