Windows Installer 和 WiX 的创建
我们目前使用 WiX 来构建 MSI 文件，因此它是我有过使用经验的唯一 MSI 构建器。我知道您可以在 Visual Studio 中本地构建安装程序。使用 WiX 和 Windows Installer 有什么区别，各自的优缺点是什么？
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我只想添加一些有关 Windows Installer 技术本身的更具体的技术信息，以及导致创建 WiX 工具包的一些历史由于刚刚进入安装程序、WiX 和 Windows Installer 领域的人可能会发现这篇文章。
本文旨在从开发人员的角度快速介绍WiX和MSI。还有一篇颇受欢迎的 serverfault.com 文章可能有助于了解 Windows Installer 的优势：使用 MSI 文件给企业带来的好处（很多开发者不喜欢 Windows Installer，但企业部署的好处其实相当显着 -如果您认为 MSI 带来的麻烦比其价值更大，也许值得快速浏览一下）。
WiX 工具包 MSI 文件的起源
本质上是从存储为 COM-结构化存储文件。这是 Microsoft Office 中使用的文件格式（请注意，MS Office 过去使用 OLE / COM 文件 - 但较新版本现在使用 Office Open XML)，它被设计为一种在单个文件中存储分层数据的方法。本质上是一个文件内的文件系统，具有各种类型的存储流 - 其中之一是要安装在一个或多个 cab 文件 。
早期的 MSI 文件/数据库最好直接使用第三方工具进行修改，例如 InstallShield 、高级安装程序 和
Wise Package Studio（由于以下原因不再可用）法律问题 - 参见当前可用的 MSI 工具的比较)。这些工具以其本机“可安装”格式将 MSI 文件存储为 COM 结构存储文件。这意味着您的 MSI 文件既是源文件又是可执行文件 - 并且采用二进制格式。这使得安装项目的源代码控制变得困难。不同 MSI 数据库上的二进制差异非常困难，而且由于数据库引用完整性，即使 MSI 中最基本的更改也会级联到数十个表，即使经过训练的眼睛也很难看到发生了什么变化。WiX 的出现是为了让开发人员能够从常规文本源文件创建二进制 MSI 文件。就像常规 EXE 二进制文件一样，MSI 二进制文件是从 WiX 文本 XML 文件“编译”的。在管理发布流程和了解 MSI 文件中的更改方面，这是一个巨大的飞跃。该工具包非常全面，对于开发人员来说更加直观，并且具有一定程度的“自动魔力”，因为它可以使开发人员免受 MSI 数据库模式的一些复杂性的影响，因为更改是使用其自己的模式以 XML 格式进行的，而不是数据库本身。 实际上，WiX 将 MSI 从数据库起源带入当今的“XML 时代”，以便开发人员可以使用文本文件，并且 MSI 文件可以被视为已编译的可执行文件，而不是数据库源文件。
< strong>实际上，无需过多了解 MSI 文件的内部工作原理，就可以制作良好的 MSI 文件 - 只要您遵循 WiX 最佳实践 - 并且相信我，作为一名开发人员，您将希望远离 MSI 文件。它们很复杂，并且对于开发人员的思维方式来说明显是非正统且违反直觉的。它与将整个安装程序存储为单个数据库的复杂性有关。它几乎完全是声明性的，而不是过程性的 - 但有些部分是连续的并定义安装顺序。许多活动部件和“阴谋复杂性”的发条装置（当你认为一切都很好时发现的陷阱）。
这些排序结构是 MSI 中最复杂的部分，涉及“提升权限”和作为数据库事务运行的文件系统操作。当你作为开发人员学习 MSI 时，你一定会觉得“这个设计有问题”，而事实是整个技术是围绕 Office 的部署要求设计的当时 -它变得非常复杂。此外，MSI 文件可能是未来事物的预览 - 也许 Windows 将来会使用 SQL Server 作为其主要存储解决方案，而 MSI 是将部署转变为“声明性语言”或庞大的 SQL 语句的第一步部署期间目标系统上会发生什么情况？但这只是猜测。
一些实用的 WiX 建议
保持简单，遵循最佳实践，无论你做什么，都不要对抗设计 - 它会反击。如果 WiX 无法做到这一点，它可能会试图帮助您避免部署问题。与您的经理要求简化或更改需求，而不是 MSI - 这一次会更容易:-)。
大多数时候，我们发现不寻常的设置设计和自定义操作的使用会导致很多不必要的复杂性，或者部署反模式（如果您愿意的话），并且通常可以通过应用程序设计中的微小更改或使用内置 MSI 结构来避免该问题。优秀的管理者会努力简化部署，但他们需要理解为什么这是必要的。我喜欢许可作为一个示例，说明如何通过避免老式或不必要的复杂应用程序和部署解决方案来以不同的方式做事并简化部署。
避免不必要的（读/写）自定义操作不惜一切代价 - 它们使设置的复杂性和风险增加了四倍。在 StackOverflow 上询问并搜索以查看是否有内置替代方案。在大多数或至少很多情况下，MSI 中有等效的内置构造来完成工作。
这个特别的建议怎么强调都不为过。在我个人看来，只读自定义操作（可能会设置属性) 相反：它们是推荐的。在大多数情况下，它们不会造成显着的额外风险 - 因为它们不会对需要回滚支持的系统进行任何更改，并且可以非常有效地将设置逻辑收集到一个地方 - 并且至关重要的是，它们在同事之间工作得很好，以允许接听使用简单的脚本语言编写时彼此的工作，例如
JavaScript（某些处理 MSI 时的笨拙方面API）或 VBScript （错误处理和整体语言功能较差，但经过了 MSI API 的良好测试。坦率地说，微软似乎正在试图“杀死”这种语言，至少 JavaScript 在网络领域的大量使用中是“活跃且良好”的。总结一下与脚本有关的事情：部署专家普遍认为，所有类型的脚本操作通常都难以调试，容易受到防病毒干扰 并且缺乏实现高级编码结构所需的语言功能。结论：很难使用任何类型的脚本编写健壮的代码。代码自定义操作是可能的（.NET），但由于它们的要求当安装 .NET 时，安全的建议是用 C++ 编写自定义操作。这允许最小的依赖性、非常好的调试和高级语言结构。这里有一个关于这个问题的长“讨论”：不同自定义操作类型的优缺点（不太好，只是现实世界的转储 经验）。不过，可能值得浏览一下 - 自定义操作是部署失败的主要原因（链接到我的针对他们的宣传），这给我们带来了下一点：部署的整体复杂性（以及如何处理它）。
部署的复杂性
部署是将异构目标计算机从一种稳定状态迁移到另一种稳定状态的复杂过程 - 这需要一种严格的方法因为：
部署是一个简单的概念，具有复杂的变量组合，可能会导致最神秘的错误 - 包括开发人员最喜欢的：间歇性错误。众所周知，此类错误的严重性怎么强调都不为过，因为它们通常无法正确调试。
有关部署以及现代安装程序可能需要执行的操作的更多信息：什么是安装程序的好处和真正目的？。这是设置需要执行哪些任务的摘要，其中包含各种技术细节。可能添加了太多细节，可能破坏了答案的“概述质量”。然而，其目的是保持与开发人员的相关性。
相关 MSI 工具
Visual Studio MSI 项目文件是一种创建 MSI 文件作为 Visual Studio 一部分的轻量级方法，其功能集极其有限。有人讨论用 WiX XML 项目替换 Visual Studio 中的 MSI 项目类型，这通常是人们现在构建 MSI 文件的方式。不要使用此项目类型。由于缺乏灵活性和严重的错误，它给许多用户带来了严重的问题。
虎鲸是Windows SDK工具，允许打开、编辑二进制MSI文件并在一定程度上进行比较。事实上，它主要是由后来创建 WiX 工具包的人编写的。 Rob Mensching 当时他在 Microsoft Windows Installer 团队工作< /强>。该工具还允许其他操作，例如生成用于修改 MSI 文件的转换文件和一些其他技术操作。尽管它是一个非常基本的工具，缺乏商业工具中提供的最高级功能，但它仍然是应用程序打包者最喜欢的使用，并且可用于调试和小修复< /strong> 由于其可靠性、简单和“清洁” - 保存时不会向 MSI 添加“默认垃圾” （第三方工具添加自定义表格和类似的垃圾）。我将它用于小型 MSI 更新、调试、检查摘要流、创建基本转换、查看补丁 , 包验证，以及其他重要操作。
事实上，我认为它是一个高级工具，具有简单的界面 - 而不是一个基本工具:-)。为了获得 Orca，您需要安装 Windows SDK（！）。当该工具的大小如此之小时，确实有点过头了，但至少很容易知道它在哪里可用，而不是寻找单独的下载。
更新：如果您安装了 Visual Studio 和 SDK，则搜索
Orca-x86_en-us.msi并安装它。如果没有，也许有安装了 Visual Studio 的朋友搜索一下然后发送给您？这是一个小文件。还有一些替代的免费工具可用，如下所述（向底部）：如何比较两个（或更多）MSI 文件的内容？
DTF - 部署工具Foundation 是一个 .NET 类套件，用于以编程方式处理 MSI 文件。写得很好，易于使用并且非常强大，它是 现在包含在主要的 WiX 下载中。它是任何项目中自动化企业使用 MSI 文件的关键组件。 这是 serverfault.com 上的简短回答讨论其使用并描述其基本组件。 DTF 中包含的帮助文件将帮助您快速使用该工具包，并且您将永远不会回头使用 Win32 函数或 COM 类来访问 MSI 文件。
市场上还有许多其他 Windows Installer 工具，您可以在 使用什么安装产品？ InstallShield、WiX、Wise、高级安装程序等（与上面的链接相同）。
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.
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).
The origin of the WiX toolkit
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 .
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 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.
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).
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.
Some practical WiX advice
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 :-).
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.
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.
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).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).
The Complexity of Deployment
Deployment is the complex process of migrating heterogeneous target computers from one stable state to another - this requires a disciplined approach since:
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.
Related MSI Tools
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.
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.
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.
UPDATE: If you have Visual Studio and the SDK installed search for
Orca-x86_en-us.msiand 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.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 - 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.
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).
WiX 创建使用 Windows Installer 的 MSI 包。因此 WiX 使用 Windows Installer 引擎。
Visual Studio 只是 WiX 的替代品，只是另一个设置创作工具。我不推荐它，因为它非常有限。它仅提供基本功能。
如果您对 WiX 感到满意，请继续使用它。
WiX creates MSI packages which use Windows Installer. So WiX uses the Windows Installer engine.
Visual Studio is just a WiX alternative, just another setup authoring tool. I don't recommend it because it's extremely limited. It offers only basic features.
If you are happy with WiX, stay with it.