Windows Installer和WiX的创建 [英] Windows Installer and the creation of WiX
问题描述
我们目前使用WiX构建我们的MSI文件，因此，这是我有经验的唯一MSI构建器.我知道您可以在Visual Studio中本地构建安装程序.使用WiX和Windows Installer有什么区别，两者各有什么优缺点?
我只想在Windows Installer技术本身上添加一些更具体的技术信息，以及一些历史记录导致创建WiX工具包，因为刚进入安装程序，WiX和Windows Installer领域的人们可能会找到这篇文章.
这是从开发人员的角度出发的 WiX 和 MSI 的快速介绍.还有一篇颇受欢迎的serverfault.com文章，可能对了解Windows Installer的好处很有帮助: COM 结构的SQL Server数据库中剥离的存储文件..这是Microsoft Office中使用的文件格式(请注意，MS Office以前使用 OLE /COM文件-但较新的版本现在使用 Office Open XML )，设计为在单个文件中存储分层数据的一种方式.本质上是文件中具有各种类型的存储流的文件系统-其中之一是要安装在一个或多个 cab文件.
最好使用第三方工具(例如 InstallShield ，高级安装程序和 Wise Package Studio (不再由于法律问题而可用-请参阅 a比较当前可用的MSI工具).这些工具将MSI文件以其本机可安装"格式存储为COM结构化存储文件.这意味着您的MSI文件既是源文件又是可执行文件-均为二进制格式.这使安装项目的源代码控制变得困难.在不同的MSI数据库上进行二进制比较是困难的，并且由于数据库参照完整性，即使MSI中最基本的更改也将通过数十个表层叠起来，甚至对于受过训练的眼睛来说，也很难看到发生了什么更改. /p>
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结构来避免此问题.一个好的经理将允许您简化部署，但是他们需要了解为什么有必要.我喜欢 许可 作为一个示例，说明了如何通过避免过时或不必要的复杂应用程序和部署解决方案来实现不同的工作并简化部署.
不惜一切代价避免不必要的(读/写)自定义操作-它们使设置的复杂性和风险增加了三倍.在堆栈溢出"中询问此处，然后搜索是否有内置的替代方法.在大多数或至少很多情况下，MSI中都有等效的内置结构可以完成工作.
此特殊建议不可夸大.我个人认为，只读自定义操作(可以设置属性)相反:建议使用.在大多数情况下，它们不会造成明显的额外风险-因为它们无需更改需要回滚支持的系统，并且可以非常有效地用于在一个地方收集设置逻辑-并且至关重要的是，它们在同事之间可以很好地工作，以允许接机使用简单的脚本语言(例如 JavaScript )(某些在处理MSI API时有些笨拙)或 VBScript (错误处理和总体语言功能差，但使用MSI API进行了良好的测试.坦率地说，微软似乎正在试图杀死"该语言.JavaScript在网络资源中的大量使用至少是有效的".
关于脚本的总结:部署专家普遍同意，所有类型的脚本操作通常难以调试，容易受到防病毒攻击和缺少语言功能来实现高级编码结构.结论:很难用任何类型的脚本编写健壮的代码. strong>可以执行托管代码自定义操作(.NET)，但是由于要安装.NET的要求，因此安全的建议是使用C ++编写自定义操作.这允许最小的依赖关系，非常好的调试和高级的语言构造.这里有一个长期的讨论"问题:自定义操作是部署失败的主要原因 (链接到我对他们的宣传)，这使我们接下来的一点:部署的整体复杂性(以及如何处理).
部署的复杂性
部署是将异构目标计算机从一种稳定状态迁移到另一种稳定状态的复杂过程-这需要一种有纪律的方法，因为:
- 错误本质上是累积性的-您尝试快速解决问题的次数越多，通常会导致更多问题.很快您将无法维护，因为该问题通常是无用的"(已发布)，必须像交付过程一样进行处理-每个迭代都有其自身的附加风险，而不仅仅是一个单一的问题.调试，直到修复为止.
- 当您无法访问相关系统时，错误很难调试.正确完成日志可以提供帮助，但是当您需要调试时日志通常不会交付给您，或者日志格式或冗长不正确，或者只是自定义操作通常无法正确记录日志，因此根本没有用. li>
- 目标系统(和目标环境)几乎在所有可以想象的方式上都不同(即使是标准操作环境(SOE)，情况也是如此，因为大多数公司都使用标准化的OS安装和软件包):硬件和驱动程序的差异(大小)，胖客户端/瘦客户端，终端服务器，操作系统平台(x86/x64/etc ...)，操作系统版本(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，Etc ...).它一直在继续.
部署是一个简单的概念，复杂的变量组合可能导致最神秘的错误-包括开发人员喜欢的间歇性错误.众所周知，此类错误的严重性不能高估，因为通常无法正确调试.
有关部署以及现代安装程序可能需要做什么的更多信息:
Visual Studio MSI项目文件是创建MSI文件(作为Visual Studio的一部分)的一种轻量级方法，它的功能集受到极大限制.有人在讨论将Visual Studio中的MSI项目类型替换为WiX XML项目，这通常是人们现在构建其MSI文件的方式.不要使用此项目类型.由于缺乏灵活性和严重的错误，它给许多用户造成了严重的问题. Orca 是 Windows SDK 工具，它允许打开，编辑二进制MSI文件并在一定程度上进行比较.实际上，它主要是由后来创建WiX工具包的人编写的. Rob Mensching ，当时他在Microsoft的 Windows Installer团队工作.该工具还允许其他操作，例如生成用于修改MSI文件的转换文件和其他一些技术操作.尽管这是一个非常基本的工具，缺少商用工具中提供的最先进的功能，但它仍然是最受应用程序打包程序青睐的，并且可以用于调试和小补丁，因为它具有可靠性，简单性和"清洁度"-在保存时不会向MSI添加默认垃圾" (第三方工具会添加自定义表格和类似的垃圾邮件).我将其用于小型MSI更新，调试， Windows SDK (！).当工具的大小很小时，确实有点超出顶部，但是至少很容易知道它在哪里可用，而不是寻找单独的下载内容. 更新:如果已安装Visual Studio和SDK，请搜索并安装 还有一些可供选择的免费工具，如此处所述(朝下): 现已包含在主要的WiX下载中 .它是任何项目中的关键组成部分，用于 MSI文件的公司自动使用. 以下是关于serverfault.com的简短答复 ，讨论了其用法并描述了其基本组成部分. DTF包含的帮助文件将使您快速使用该工具包，并且永远不会回过头来使用Win32函数或COM类来访问MSI文件. 市场上还有许多其他Windows Installer工具，您可以在 解决方案
相关的MSI工具
Orca-x86_en-us.msi.如果您不这样做，也许有一个安装了Visual Studio的朋友搜索它，然后将其发送给您?这是一个小文件.
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:
- 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.
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.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.
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).
这篇关于Windows Installer和WiX的创建的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
