Windows Installer 和 WiX 的创建 [英] Windows Installer and the creation of WiX
问题描述
我们目前使用 WiX 来构建我们的 MSI 文件，因此它是我使用过的唯一一个 MSI 构建器.我知道您可以在 Visual Studio 中本地构建安装程序.使用 WiX 和 Windows Installer 之间有什么区别，各自的优缺点是什么?
We currently use WiX for building our MSI files, and as such it is the only MSI builder I have had experience using. I know you can build installers natively in Visual Studio though. What are the differences between using WiX and Windows Installer, and what the pros and cons are of each?
推荐答案
我只想添加一些关于 Windows Installer 技术本身的更具体的技术信息，以及一些历史 导致 WiX 工具包的创建，因为这篇文章可能会被刚刚进入安装程序、WiX 和 Windows 安装程序领域的人找到.
I just want to add some more specific technical information on the Windows Installer technology itself, and some of the history leading up to the creation of the WiX toolkit since this post may be found by people who are just getting into the field of installers, WiX and Windows Installer.
本文旨在从开发人员的角度快速介绍WiX和MSI.还有一篇颇受欢迎的 serverfault.com 文章可能有助于了解 Windows Installer 的好处:使用 MSI 文件的企业好处(许多开发人员不喜欢 Windows Installer，但企业部署的好处实际上非常重要 - 如果您认为 MSI，也许值得快速浏览一下麻烦多于值得).
This is intended as a quick introduction to WiX and MSI from a developer's perspective. There is also a somewhat popular serverfault.com article that might be useful to grasp Windows Installer's benefits: The corporate benefits of using MSI files (many developers dislike Windows Installer, but the corporate deployment benefits are actually quite significant - perhaps worth a quick skim if you think MSI is more trouble than it is worth).
MSI 文件本质上是精简的 SQL Server 数据库，存储为 COM 结构 这是 Microsoft Office 中使用的文件格式(注意 MS Office 过去使用 OLE/COM 文件 - 但较新的版本现在使用 Office Open XML)，它是旨在将分层数据存储在单个文件中.本质上是文件内的文件系统，具有各种类型的存储流 - 其中之一是要安装在一个或多个 cab 文件 .
MSI files are essentially stripped down SQL Server databases stored as COM-structured storage files. This is the file format used in Microsoft Office (note that MS Office used to use OLE / COM files - but newer versions now use Office Open XML), and it was designed as a way to store hierarchical data within a single file. Essentially a file system within a file with storage streams of various types - one of which is the files to install inside one or more cab files .
早期的 MSI 文件/数据库最好使用第三方工具直接修改，例如 InstallShield、高级安装程序 和 Wise Package Studio(不再由于法律问题可用 - 请参阅a当前可用 MSI 工具的比较).这些工具将 MSI 文件以其原生的可安装"格式存储为 COM 结构化存储文件.这意味着您的 MSI 文件既是源文件又是可执行文件 - 并且是二进制格式.这使您的安装项目的源代码控制变得困难.不同 MSI 数据库上的二进制差异很困难，并且由于数据库参照完整性，即使是 MSI 中最基本的更改也会通过数十个表级联，即使训练有素的眼睛也很难看到发生了什么变化.
Early on MSI files / databases were best modified directly using third-party tools such as InstallShield, Advanced Installer and Wise Package Studio (no longer available due to legal issues - see a comparison of currently available MSI tools).These tools stored the MSI file in its native "installable" format as a COM structured storage file. This meant your MSI file was both source and executable - and in binary format. This made source control of your installation project difficult. Binary diffs on different MSI databases were difficult, and due to database referential integrity even the most basic changes in the MSI will cascade through dozens of tables and make it difficult to see what changed even for trained eyes.
WiX 的出现是为了让开发人员允许从常规文本源文件创建二进制 MSI 文件. 就像常规 EXE 二进制文件一样，MSI 二进制文件是从 WiX 文本编译"的XML 文件.在管理您的发布流程和了解 MSI 文件中的更改方面，这是一个巨大的飞跃.该工具包对开发人员来说非常全面和直观，并具有一定程度的自动魔术"功能，因为它使开发人员免受 MSI 数据库模式的一些复杂性的影响，因为更改是以具有自己的模式的 XML 格式进行的，而不是数据库本身.实际上，WiX 将 MSI 从其数据库起源带入了当今的XML 时代"，以便开发人员可以使用文本文件，并且可以将 MSI 文件视为已编译的可执行文件，而不是数据库源文件.
WiX came around as a way for developers to allow the creation of a binary MSI file from regular text source files. Just like a regular EXE binary, an MSI binary is "compiled" from WiX text XML files. This is a quantum leap in terms of managing your release process and understanding changes in the MSI file. The toolkit is very comprehensive and much more intuitive for a developer and features a degree of "automagic" in that it shields the developer from some of the intricacies of the MSI database schema since changes are made in an XML format with its own schema and not the database itself. In effect WiX takes MSI from its database origins into the "XML age" of today so that developers work with text files, and the MSI files can be seen as compiled executables as opposed to database source files.
实际上可以制作好的 MSI 文件，而无需对 MSI 文件的内部工作了解太多 - 只要您遵循 WiX 最佳实践 - 并且相信我作为一名开发人员，您会希望留下出 MSI 文件.对于开发人员的思维方式来说，它们很复杂，而且非常非正统和违反直觉.它与将整个安装程序存储为单个数据库的复杂性有关.它几乎完全是声明性的而不是程序性的——但有些部分是连续的并定义了安装顺序.许多活动部件和阴谋复杂性"的发条(当你认为一切都很好时发现的陷阱).
It is actually possible to make good MSI files without knowing too much about the inner workings of the MSI file - provided you follow WiX best practices - and trust me as a developer you will want to stay out of MSI files. They are complex, and distinctively unorthodox and counterintuitive for a developer mindset. It has to do with the complexity of storing a whole installer as a single database. It is almost entirely declarative and not procedural - but some parts are sequential and define installation order. Lots of moving parts and a clockwork of "conspiratory complexity" (gotchas that you discover as you thought everything was fine).
这些排序结构是 MSI 中一些最复杂的部分，涉及提升权限"和作为数据库事务运行的文件系统操作.当您作为开发人员学习 MSI 时，您一定会觉得这种设计有问题"，而事实是，整个技术是围绕当天的 Office 部署要求设计的 -它变得非常复杂.此外，MSI 文件可能是未来事物的预览——也许 Windows 将来会使用 SQL Server 作为其主要存储解决方案，而 MSI 是将部署转变为声明性语言"或巨大 SQL 语句的第一步.部署期间会在目标系统上发生吗?不过这只是猜测.
These sequencing constructs are some of the most complex parts of an MSI involving "elevated rights" and file system operations run as a database transaction. When you learn MSI as a developer you are bound to feel that "something is wrong with this design", and the truth is that the whole technology was designed around the deployment requirements for Office back in the day - and it became as complex as it had to be. Furthermore MSI files may be a preview of things to come - perhaps Windows will use SQL Server as its main storage solution in the future, and MSI is the first step in turning deployment into a "declarative language" or a huge SQL statement for what is going to happen on the target system during deployment? This is just speculation though.
保持简单，遵循最佳实践，无论您做什么都不会与设计抗争——它会反击.如果 WiX 不能做到，它可能会试图帮助您避免部署问题.与您的经理对抗以简化或更改要求，而不是 MSI - 一次更容易:-).
Keep it simple, follow best practice and whatever you do don't fight the design - it fights back. If WiX can't do it, it is likely trying to help you avoid deployment problems. Fight your manager to simplify or change requirements, not MSI - for once it's easier :-).
大多数时候我们发现不寻常的设置设计和自定义操作的使用会导致很多不必要的复杂性，或者部署反模式，如果您类似，并且该问题通常可以通过应用程序设计中的小改动或使用内置 MSI 结构来避免.一个好的管理者会允许努力简化部署，但他们需要了解为什么这是必要的.我喜欢许可作为一个示例，说明如何通过避免过时的或不必要的复杂应用程序和部署解决方案，以不同方式做事并简化部署.
Most of the time we find that unusual setup designs and the use of custom actions cause a lot of unnecessary complexity, or deployment anti-patterns if you like, and the problem can often be avoided by small changes in application design, or the use of built-in MSI constructs. A good manager will allow efforts to simplify deployment, but they need to understand why it is necessary. I like licensing as an example of how you can do things differently and make deployment simpler by avoiding old fashioned or needlessly, complicated application and deployment solutions.
不惜一切代价避免不必要的(读/写)自定义操作 - 它们会使设置的复杂性和风险增加四倍.在 Stack Overflow 上询问这里并搜索以查看是否有内置替代方案.在大多数或至少许多情况下，MSI 中有等效的内置结构来完成工作.
Avoid unnecessary (read/write) custom actions at all cost - they quadruple a setup's complexity and risk. Ask here on Stack Overflow and search to see if there is a built-in alternative. In most or at least many cases, there are equivalent built-in constructs in MSI to get the job done.
这个特别的建议不能被夸大.在我个人看来，只读自定义操作(可能设置属性) 则相反:它们是推荐的.在大多数情况下，它们不会造成显着的额外风险——因为它们不会对需要回滚支持的系统进行任何更改，并且可以非常有效地用于在一个地方收集设置逻辑——而且至关重要的是，它们在同事之间工作得很好，允许拿起使用简单的脚本语言编写时彼此的工作，例如 JavaScript(一些处理 MSI API 时的笨拙方面)或 VBScript(糟糕的错误处理和整体语言功能，但使用 MSI API 进行了很好的测试.坦率地说，微软似乎正试图杀死"该语言.JavaScript 至少在大量用于网络内容的情况下活跃").
This particular advice can not be overstated. In my personal opinion, read-only custom actions (that may set properties) are the opposite: they are recommended. They do not cause significant extra risk in most cases - since they make no changes on the system requiring rollback support, and can be used very effectively to gather setup logic in one place - and crucially they work well between co-workers to allow picking up each other's work when written in simple scripting languages such as JavaScript (some clunky aspects when dealing with the MSI API) or VBScript (poor error handling and overall language features, but well tested with the MSI API. Frankly it seems like Microsoft is trying to "kill" the language. JavaScript is at least "alive and well" in heavy use for web-stuff).
总结关于脚本的事情:部署专家普遍认为，所有类型的脚本操作通常难以调试，容易受到反病毒攻击干扰和缺乏实现高级编码结构所需的语言特性.总结:很难用脚本编写健壮的代码 - 任何类型.strong> 托管代码自定义操作是可能的 (.NET)，但由于它们需要安装 .NET，因此安全的建议是用 C++ 编写自定义操作.这允许最少的依赖、非常好的调试和高级语言结构.这里有一个很长的讨论":不同自定义操作类型的优缺点(不太好，只是现实世界经验的转储).不过可能值得一读 - 自定义操作是部署失败的主要原因(链接到我针对他们的宣传)，这让我们下一点:部署的整体复杂性(以及如何处理).
To wrap up things with regards to scripts: there is general agreement among deployment specialists that script actions of all types are in general hard to debug, vulnerable to anti-virus interference and lacking in language features needed to implement advanced coding constructs. In conclusion: it is hard to write robust code with scripts - of any type. Managed code custom actions are possible (.NET), but due to their requirement of .NET being installed, the safe recommendation is to write custom actions in C++. This allows minimal dependencies, very good debugging and advanced language constructs. There is a long "discussion" of this issue here: pros and cons of different custom action types (not great, just a dump of real-world experience). It might be worth a skim though - custom actions are the leading cause of deployment failures (link to my propaganda against them), and this brings us to the next point: the overall complexity of deployment (and how to deal with it).
部署是将异构目标计算机从一种稳定状态迁移到另一种稳定状态的复杂过程 - 这需要严格的方法，因为:>
Deployment is the complex process of migrating heterogeneous target computers from one stable state to another - this requires a disciplined approach since:
- 错误本质上是累积性的 - 您越是尝试快速修复，就越经常会导致更多问题.很快您就无法维护，因为问题通常是不确定的"(已发布)并且必须像交付过程一样处理 - 每次迭代都有其自己的附加风险，而不仅仅是一个问题调试，直到得到修复.
- 当您无法访问相关系统时，错误极难调试.如果做得好，日志记录会有所帮助，但是当您需要调试时，它通常不会交付给您，或者它的格式或冗长错误，或者完全无用，因为自定义操作通常无法正确记录内容.
- 目标系统(和目标环境)在几乎所有可以想象的方面都不同(即使是标准操作环境 (SOE) 也是如此，因为大多数公司使用标准化的操作系统安装和包):硬件和驱动程序差异(大和小)、胖客户端/瘦客户端、终端服务器、操作系统平台(x86/x64/等...)、操作系统版本(Win7、Win10、WinXP等...)，操作系统版本(终极版、家庭版等)、操作系统语言版本、操作系统升级状态和补丁级别、恶意软件情况、磁盘空间问题、分区方案、文件系统类型、加密问题(文件系统、网络)、用户权限设置、UAC配置、系统权限配置(NTRights)、连接类型、连接速度、网络配置(域、工作组等...)、子网、代理设置、电子邮件系统和配置(Exchange、Outlook、Novell 等...)、活动目录、身份验证方案、网络rk 共享和驱动器、应用程序资产、脚本可用性、脚本锁定、各种运行时版本(C、C++、MFC、ATL、ADO、OLE DB、ADO.NET、Java、脚本运行时)、COM 和 DCOM 对象注册和配置、COM+、IIS 和 Web 服务器、路径变量和环境变量、文件关联和外壳操作、无线软件设置、用户数量、.NET 版本和配置、语言包、GAC 和 WinSxS 状态和配置(策略文件)、软件防火墙、模拟/虚拟化系统、部署系统(SCCM、Tivoli 等...).它一直持续下去.
- Errors are cumulative in nature - you often cause more problems the more you try to fix things with a quick fix. Pretty soon you have an impossibility to maintain on your hands since the problem is generally "in the wild" (published) and must be dealt with like a delivery process - each iteration with its own, added risk, and not just a single problem to debug until you have a fix.
- Errors are extremely hard to debug when you have no access to the system in question. Logging can help when done right, but it is often not delivered to you when you need it for debugging, or it is in the wrong format or verbosity, or just plain useless altogether since custom actions often don't log things properly.
- The target systems (and target environment) differ in just about every way imaginable (this is the case even if it is a standard operating environment (SOE) as most companies use with standardized OS installations and packages): hardware and driver differences (large and small), fat client / thin client, terminal server, OS platform (x86/x64/etc...), OS version (Win7, Win10, WinXP, etc...), OS edition (ultimate, home, etc...), OS language version, OS upgrade status and patch level, malware situation, disk space issues, partitioning scheme, file system types, encryption issues (file system, network), user rights setup, UAC configuration, system privilege configuration (NTRights), connection type, connection speed, network configuration (domain, workgroup, etc...), sub-netting, proxy setup, email system and configuration (Exchange, Outlook, Novell, etc...), active directory, authentication scheme, network shares and drives, application estate, scripting availability, scripting lock-down, all kinds of runtime versions (C, C++, MFC, ATL, ADO, OLE DB, ADO.NET, Java, scripting runtimes), COM and DCOM object registration and configuration, COM+, IIS and web servers, path variables and environmental variables, file associations and shell operations, wireless software setup, number of users, .NET versions & configuration, language packs, GAC and WinSxS state and configuration (policy files), software firewalls, emulated / virtualized systems, deployment system (SCCM, Tivoli, Etc...). It goes on and on.
部署是一个简单的概念，包含可能导致最神秘错误的复杂变量组合 - 包括开发人员最喜欢的:间歇性错误.众所周知，此类错误的严重性怎么强调都不为过，因为它们通常无法正确调试.
Deployment is a simple concept, with a complicated mix of variables that can cause the most mysterious errors - including the developer favorite: the intermittent bug. As we all know the seriousness of such bugs can not be overstated as they are often impossible to debug properly.
更多关于部署和现代安装程序可能需要做什么:安装程序的好处和真正目的是什么?.这是一个设置可以完成哪些任务的摘要，其中包含各种技术细节.可能添加了太多细节，可能会破坏答案的概述质量".然而，目的是与开发者保持相关性.
More on deployment and what a modern setup program might need to do: What is the benefit and real purpose of program installation?. This is a summary of what tasks a setup can be required to do peppered with various technical details. Too many details may have been added, perhaps destroying the "overview quality" of the answer. However the intent is to stay relevant for developers.
Visual Studio MSI 项目文件 是一种创建 MSI 文件作为 Visual Studio 一部分的轻量级方法，它的功能集极其有限.有讨论用 WiX XML 项目替换 Visual Studio 中的 MSI 项目类型，这通常是人们现在构建 MSI 文件的方式.不要使用这种项目类型.由于缺乏灵活性和严重的错误，它给许多用户带来了严重的问题.
A Visual Studio MSI project file is a light-weight way to create an MSI file as part of Visual Studio, and it was extremely limited in its feature set. There were talks to replace the MSI project type within Visual Studio with a WiX XML project, and this is generally how people build their MSI files now. Don't use this project type. It has caused serious problems for many users due to its lack of flexibility and serious bugs.
逆戟鲸 是 Windows SDK 工具，它允许打开、编辑二进制 MSI 文件并进行一定程度的比较.事实上，它主要是由后来创建 WiX 工具包本身的人编写的.Rob Mensching，当时他在 Microsoft Windows Installer 团队工作.该工具还允许其他操作，例如生成用于修改 MSI 文件的转换文件和一些其他技术操作.尽管它是一个非常基本的工具，缺乏商业工具中提供的最高级功能，但它仍然是应用程序打包者的最爱，可以用于调试和小修复 由于其可靠性、简单和清洁" - 保存时不会向 MSI 添加默认垃圾"(第三方工具添加自定义表和类似的垃圾).我将它用于小型 MSI 更新、调试、检查摘要流，创建基本变换，查看补丁、包验证等重要操作.
Orca is the Windows SDK tool which allows binary MSI files to be opened, edited and to a certain degree compared. It was in fact written mostly by the man who later created the WiX toolkit itself. Rob Mensching while he was working in the Windows Installer team at Microsoft. The tool also allows other operations such as generating transform files for modifying the MSI files and some other technical operations. Though it is a very basic tool lacking most advanced features available in commercial tools, it remains an application packager favorite to use and have available for debugging and small fixes due to its reliability, simplicity and "cleanliness" - it doesn't add "default junk" to an MSI when saving it (third-party tools add custom tables and similar junk). I use it for small MSI updates, debugging, inspection of the summary stream, creation of basic transforms, viewing patches, package validation, and other important operations.
事实上，我猜它是一个高级工具，界面简单——根本不是基本工具:-).为了获得 Orca，您需要安装 Windows SDK (!).当工具的大小如此之小时，确实有点过分，但至少很容易知道它在哪里可用，而不是寻找单独的下载.
In fact, I guess it is an advanced tool, with a simple interface - and not a basic tool at all :-). In order to get hold of Orca, you need to install the Windows SDK (!). A bit over the top really when the size of the tool is so small, but at least it is easy to know where it is available instead of hunting for a separate download.
更新:如果您安装了 Visual Studio 和 SDK，请搜索 Orca-x86_en-us.msi 并安装它.如果没有，也许有安装了 Visual Studio 的朋友搜索它然后发送给你?这是一个小文件.
UPDATE: If you have Visual Studio and the SDK installed search for Orca-x86_en-us.msi and install it. If you don't, maybe have a friend with Visual Studio installed search for it and then send it to you? It is a small file.
还有一些替代的免费工具可用，如下所述(向底部):如何比较两个(或多个)MSI 文件的内容?
There are also some alternative, free tools available as described here (towards bottom): How can I compare the content of two (or more) MSI files?
DTF - 部署工具基础是一个 .NET 类套件，用于以编程方式处理 MSI 文件.写得好，易于使用且非常强大，它是 现在包含在主要的 WiX 下载中.在任何项目中，它都是企业使用 MSI 文件的自动化的关键组件.这里是关于 serverfault.com 的简短回答，讨论了它的使用并描述了它的基本组件.DTF 中包含的帮助文件将使您快速使用该工具包，而且您永远不会回头使用 Win32 函数或 COM 类来访问 MSI 文件.
DTF - Deployment Tools Foundation is a .NET suite of classes to deal with MSI files programatically. Well written, easy to use and very powerful it is now included with the main WiX download. It is a crucial component in any project to automate corporate use of MSI files. Here is a brief answer on serverfault.com discussing its use and describing its basic components. The help files included with DTF will get you going quickly with the toolkit, and you will never look back at using Win32 functions or COM classes to access MSI files.
市场上还有许多其他 Windows Installer 工具，您可以在 使用什么安装产品?InstallShield、WiX、Wise、Advanced Installer 等(与上述链接相同).
There are many other Windows Installer tools on the market, and some of them you can find compared to WiX at What installation product to use? InstallShield, WiX, Wise, Advanced Installer, etc (same link as above).
这篇关于Windows Installer 和 WiX 的创建的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
