Windows Installer和WiX的创建

前端之家收集整理的这篇文章主要介绍了Windows Installer和WiX的创建前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我们目前使用WiX来构建我们的MSI文件,因此它是我使用过的唯一的MSI构建器.我知道您可以在Visual Studio中本机构建安装程序.使用WiX和 Windows Installer有什么区别,以及各自的利弊?
我只想在Windows Installer技术本身添加一些更具体的技术信息,以及导致WiX工具包创建的一些历史,因为这篇文章可能会由刚刚进入安装程序领域的人们发现,WiX和Windows安装程序.

这是为了从开发者的角度快速介绍WiX和MSI.还有一个受欢迎的serverfault.com文章可能有助于掌握Windows Installer的优势:The corporate benefits of using MSI files.

WiX工具包的起源

MSI文件基本上被删除存储为COM结构化存储文件sql Server数据库.这是Microsoft Office中使用的文件格式,它被设计为在单个文件中存储分层数据的一种方式.本质上是文件中的文件系统,其中包含各种类型的存储流,其中之一是要安装在一个或多个cab files内的文件.

早期的MSI文件/数据库最好使用第三方工具(如InstallShield和Wise Package Studio)进行直接修改.这些工具将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结构.一个好的经理将允许努力简化部署,但他们需要了解为什么是必要的.我喜欢licensing作为一个例子,你可以做不同的事情,并通过避免旧的或不必要的,复杂的应用程序和部署解决方案使部署更简单.

避免不必要的(读/写)自定义操作 – 它们使设置的复杂性和风险增加了四倍.在Stack Overflow上查询,查看是否有内置的替代方法.在大多数或至少很多情况下,在MSI中有相同的内置结构来完成工作.

这个特别的建议不能夸大.在我个人看来,只读自定义操作(可能设置属性)是相反的:它们被推荐.它们在大多数情况下不会造成重大的额外风险 – 因为它们在需要回滚支持的系统上没有任何变化,并且可以非常有效地用于在一个地方收集设置逻辑 – 并且至关重要的是在VBScript写入同事之间工作良好脚本或类似的简单脚本语言. Not everyone agrees with me on this issue. Here is a better explanation in context.这里是forum.installsite.net.

部署的复杂性

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

>错误本质上是累积性的 – 您经常会导致更多的问题,您尝试通过快速修复来解决问题.很快,你不可能保持在你的手上,因为这个问题一般都是“在野外的”(发表),而且必须像一个交付过程一样处理 – 每次迭代都有自己的风险,而不仅仅是一个问题调试,直到你有一个修复.
>当您无法访问有问题的系统时,错误很难调试.记录可以在正确的情况下帮助,但是当您需要调试时,它通常不会传递给您,或者是错误的格式或冗长性,或者完全无用,因为自定义操作通常不会正确记录事件.
>目标系统各不相同(即使是标准操作环境(SOE),大多数公司都使用标准化操作系统安装和软件包),硬件和驱动程序差异(大小),操作系统版本和补丁级别,语言版本,升级状态,恶意软件情况,磁盘空间,分区方案,用户权限设置,连接速度,代理解决方案,应用程序,脚本锁定,运行时版本,无线软件设置,用户数等…

部署是一个简单的概念,复杂的变量组合可能会导致最神秘的错误包括开发人员的喜好:间歇性错误.任何认真的工作和被质疑的人都不能夸大这种错误的严重性.

更多的部署和安装程序真的应该是:@L_403_10@

相关MSI工具

Visual Studio MSI项目文件是一种轻量级的方式来创建一个MSI文件作为Visual Studio的一部分,它的功能集非常有限.有人在谈话中用WiX XML项目替换Visual Studio中的MSI项目类型,这通常是人们如何构建他们的MSI文件.不要使用此项目类型.由于缺乏灵活性和严重错误,对许多用户造成严重问题.

Orca是Windows SDK工具,允许打开,编辑二进制MSI文件并在一定程度上进行比较.这实际上是由后来创建WiX工具包本身的人写的. Rob Mensching,而他在Microsoft的Windows Installer团队工作.该工具还允许其他操作,如生成转换文件修改MSI文件和其他一些技术操作.虽然它是一个非常基本的工具,缺乏商业工具中最先进的功能,它仍然是一个应用程序包装程序最喜欢的使用,并可用于调试和小修复,由于其可靠性,简单性和“清洁度” – 它不添加“默认垃圾“保存到MSI(第三方工具添加自定义表和类似的垃圾).我使用它来进行小型MSI更新,调试,inspection of the summary stream,创建基本转换,查看补丁,包验证等重要操作.

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

DTF – 部署工具基础是一个.NET套件,以程序方式处理MSI文件.写得很好,易于使用,非常强大的是now included with the main WiX download.它是任何项目中自动化企业使用MSI文件的关键组件. Here is a brief answer on serverfault.com讨论其使用和描述其基本组件. DTF附带的帮助文件将使您能够快速使用该工具包,您将永远不会回头看到使用Win32函数或COM类来访问MSI文件.

市面上还有许多其他Windows Installer工具,其中一些可以在What installation product to use? InstallShield,WiX,Wise,Advanced Installer,etc与WiX相比.

原文链接:https://www.f2er.com/windows/371352.html

猜你在找的Windows相关文章