使用.msi文件比常规setup.exe文件有什么优点？
我有这样的印象，即在用户拥有较less权限的机器上部署更容易，但不清楚细节。
msiexec.exe具有哪些function，比使用setup.exe场景更容易部署？
部署.msi应用程序时的任何提示或技巧？
只有几个好处：
我认为当我在企业环境中部署软件时，通过MSI部署软件几乎是件愉快的事情。 相比之下，我几乎总是发现自己害怕在另一个容器中部署软件。
有关操作MSI安装的其他信息，请在运行对话框中键入msiexec 。
作为发行经理 ， build筑工程师 ， 设置开发人员以及大型公司的应用程序打包人员和部署工程师 ，我一直从事开发工作。
这是对MSI最好的（也是最糟糕的） 概念和现实世界的回顾。 在MSI文件中发现的最常见的devise问题在下面作为单独的答案呈现。
我也想build议这个MSDN文章作为一个很好的阅读： Windows Installer：系统pipe理员的好处和实现 。
总之，微星是关于标准化的，关于处理传统安装技术的“ 部署气味 ”。 一整套糟糕的安装架构devise导致重复部署问题。
总体而言，MSI为安装程序提供了一个全面的标准化框架 ， 其中最关键的还包括可以通过远程触发的 标准化GUI进行静默运行 的卸载和内置function和选项。
这些function本身就是对以前的安装技术的巨大改进 ， 这些技术可以随意处理卸载和静默运行 – 这可能是企业部署最重要的function，同时还可以通过Active Directory或Microsoft SCCM （以前称为SMS）等专用远程pipe理工具进行可靠的远程pipe理 ， IBM Tivoli ， CA Unicenter等。
随着时间的推移，这篇文章的其余部分已经有了相当大的增长，我不确定它比以前好多了。 有人从这里复制的内容，并在一些点stackoverflow.com 。 这个较旧和较短的版本可能是一个更快的阅读。 如果人们觉得这个版本更好，会很有趣。
MSI通过devise积极劝阻传统的部署气味 。 这些主题将在后面的章节中讨论，但是作为一个快速列表，传统安装程序和旧版本部署技术最常见的问题是：
这个名单还有许多其他重要和公认的部署缺陷 。 很显然，在企业部署的世界里，这些问题最常出现，并导致“ 应用程序重新打包 ”业务，其中使用磁盘和registry扫描技术捕获旧版安装程序 ，以创build符合标准的MSI文件进行可靠的部署。
应用程序重新打包是一项专业的工作 ，如果知识丰富的人员正确地完成MSI文件，通常会产生优质的MSI文件，但由于复杂的注册逻辑必须交互式运行以便某些应用程序正常工作，所以不可能重新打包所有应用程序。
用通俗易懂的话来说，微星的真正重要的好处是（没有特定的顺序）：
在现实世界中，我发现不太成功的方面包括修补 （非常复杂）， MSI-GUI （普通function，相当复杂，缺乏灵活性）， 弹性 （可能会导致难以debugging重复的自我修复问题 ）以及整体复杂性处理初学者的技术（有时基本操作的高度复杂性 – 例如升级，GUI和许多相互作用的细节导致意想不到的结果等等）。 由于MSI的开销增加，安装过程的速度也大大减慢。 查看一些提高MSI安装速度的提示 。
本文的其余部分将更详细地介绍MSI的这些方面。
MSI文件本质上是一个精简的SQL Server数据库，存储为COM结构的存储文件 – 本质上是文件系统或数据stream集合。 这是Microsoft Office文档中使用的文件types，它产生了一个可以检查和检查的标准格式 – 对于大型公司来说是一个巨大的问题 。
除了已编译的自定义操作外，MSI文件是白色的 。 如果安装程序改变了一些疯狂的东西，比如系统的networking设置，你可以使用适当的工具来看到它。 值得注意的例外是编译自定义操作 – 这是黑匣子 。 Windows徽标要求要求自定义操作被注释以解释他们在做什么，但安装程序开发人员经常忽略这一点。 希望Wix的到来将会改善这一点。
为了确定这种编译的自定义动作实际上在技术意义上做了什么， 设置捕捉是必要的。 这在我的经验中几乎没有做过。 如果软件需要获得企业部署的批准，那么与供应商联系以获取信息更为常见，然后可能是阻止其使用的应用程序本身，而不仅仅是设置。
MSI可以通过转换来定制，以适应组织的需求和标准，同时仍然允许与供应商的安装程序更新的互操作性。 您不会更改安装程序本身，您可以在名为transform （.mst文件）的单独组织特定文件（数据库片段或更改事务）中创build自定义。 您可以自由地禁用自定义操作，并在一般情况下更改，覆盖或禁用安装程序中的任何内容，甚至可以添加新的东西，包括文件。 转换文件有时也用于将MSI文件本地化为不同的语言。 几个转换可以应用于单个MSI，下面是截断path的示例 ：
msiexec.exe /I "My.msi" /QN /L*V "C:\My.log" TRANSFORMS="C:\1031.mst;C:\My.mst"
快速参数说明：
/QN = run completely silently /L*V "C:\My.log"= verbose logging TRANSFORMS="C:\1031.mst;C:\My.mst" = Apply transforms 1031.mst and My.mst.
Windows安装程序维护一个产品已经安装在registry中的所有项目的综合数据库 （ HKEY_CLASSES_ROOT \ Installer – 不要直接改变任何东西！这也适用于专家）。
您可以可靠地确定是否安装了产品，安装了哪些function以及安装了哪些文件版本。 此外，您可以获得已应用于基本产品的所有修补程序的列表（如果有的话）。 您可以通过API的支持Win32，COM或.NET使用各种脚本，configuration和pipe理工具，如Microsoft SCCM ， IBM Tivoli ， CA Unicenter等等来访问这个数据库 。
MSI还包含“提升权利”原则 ，允许受限用户触发安装需要pipe理权限的产品。 这是“ 广告function ”的一部分，它允许pipe理员将安装程序提供给用户，而无需在所有工作站上实际安装。 安装程序本身必须在多个核心帐户上正确创作，以便使这种提升的权利概念正确工作。 用户可以自己触发产品的安装，也可以通过专用的部署系统（如SCCM，Tivoli，Unicenter（通常是大型公司））来控制安装。 没有必要混淆临时pipe理权限来使事情工作 ，而传统的安装程序往往是这样。
全面的安装数据库还确保您可以全面了解已安装的修补程序，从而可以通过自动化和pipe理工具来检测安全漏洞。
可以使用validation规则来检查MSI文件，以确保其符合许多内部一致性规则 （称为ICE ）。 公司可以创build自己的ICE检查来执行特殊的公司规则和要求。 这对QA有很大的帮助。 validation的可能原因是由于关系数据库的自引用性质和相关的数据库模式。 数据库必须内部一致，并且与外键，数据types，字段宽度，模式版本等有关的自身模式兼容。validation也超越了这一点，并且能够检测到包中的真正逻辑缺陷和错误，而不仅仅是格式和types的缺陷。 例如，它可以检测正在部署到错误目标目标的文件或文件types。
Windows安装程序的pipe理员安装function提供了从MSI中提取源文件的标准方法（ 这里是关于此主题的一些附加信息 ）。 这些源文件然后可以放在一个共享上，并可供所有工作站安装。 这可以确保修复，卸载和修改操作，而无需在CD或类似软件上请求安装介质。 这对于在特殊情况下可能需要访问旧版本源文件的修补和更新操作尤为重要。
这种弹性function也有一些常见的问题。 大多数pipe理员都有经验丰富的机器，具有永不停息的周期性自我修复周期 。 按照链接了解这个问题的一长串原因。 再次， 这是一个较短的版本 ，可能会更容易阅读。
MSI文件的安装通常会触发创build还原点 。 此外，在安装过程中replace或覆盖的所有文件和registry项将在保存并恢复（如果安装无法完成），禁止在自定义操作中完成任何更改。
自定义操作必须实现自己的Windows徽标合规回滚支持。 这经常被忽略，但涉及创build第二个自定义操作来撤消主自定义操作所做的更改。
回滚确保即使安装失败，工作站也保持稳定状态。 实际的回滚脚本直接存储在系统驱动器上的隐藏文件夹中 – 通常为C：\ Config.MSI ，并且包含具有扩展名.RBS和.RBF – 回滚脚本文件的文件 。 正如你可能期望devise不佳的MSI文件可能会违反Windows的内置function，请参阅我的其他post以获取更多详细信息。
有办法禁用回滚和加快安装。 通常不推荐，但这里是关于MSIFASTINSTALL属性和DISABLEROLLBACK的详细信息 。 这是一个复杂的function，但这里是一个快速回滚概述 。
尽pipe非常复杂，但Windows安装程序中的修补程序已完全pipe理并在系统上注册，因此可以通过检查已安装的内容来确定系统安全状态。 更新被标准化为几个基本变体，并且这允许更高程度的确定性执行更新，只要您能够处理复杂性。 部署系统将能够报告哪些更新失败以及为什么。
在一个主观的视图中，修补对于2个基本用途来说效果很好： 1 ）交付产品的小修补程序; 2 ）修补已安装的产品以修复其错误的卸载序列，从而防止产品干净卸载。
补丁只是一个 已经在使用的更新 的传递机制 。 因此，它只是一个比原来的设置本身更复杂 ，更容易出错的容器。 补丁的第一条规则是它必须比原来的MSI小，否则根本没有明显的理由提供补丁。 如果补丁针对多个产品版本，补丁可能会变得很快。
Windows安装程序提供了一个标准化的日志loggingfunction ，这是比以前的化身，虽然几乎过于详细，大大优于。 可以使用日志分析器将日志文件解密，并且可以使用自定义日志级别来消除用不必要的信息生成太大的日志文件。 为了debugging目的，详细logging是非常有用的。 请参阅Rob Mensching的博客 ，阅读MSI日志文件（本质上是在日志文件中search“ value 3 ”）。 以下是执行详细日志logging的示例命令行：
msiexec.exe /I "C:\Installer.msi" /QN /L*V "C:\msilog.log"
强烈build议您从Windows安装程序团队的 Robert Macdonald这篇文章作为MSI日志logging的实际看法： 如何解释Windows安装程序日志 。
并非所有关于Windows Installer的都是好的 。 它的复杂性有时可能会让人困惑 ，但是对于大公司来说，当考虑到上述好处时，MSI文件远远优于其他任何forms的部署。
为了理解新的“ 范式 ”，理解MSI意在作为对目标系统将要发生的事情的陈述性描述 ，而不是一系列固定的事件是很重要的。 我想你可以把它看作一个巨大的SQL语句 。 例如，将要添加或修改的项目声明为INI文件。 在安装运行时，跟踪更改并回滚可用，以便在安装失败时可以恢复更改。 这真的像“ automagic ”一样工作，而且正确的话可靠。
对于有经验的MSI开发人员来说 ，看到人们依靠复杂的，不可靠的自定义操作来更好地实现内置MSIfunction，这是一个非常头痛的问题 。 所有MSI错误和回滚问题中的重要部分是由错误的自定义操作引起的，而其他大多数错误则是由错误使用MSIdevise引起的（请参阅单独的答案以查看常见MSI错误列表）。
除了内置的MSIfunction之外，现在越来越多的定制function可以通过新的框架（如Wix–用于编译MSI文件的XML方法）提供，所以对于大多数操作来说，复杂的自定义操作逻辑的需求越来越less。
MSI支持处理ini文件设置，字体，环境variables，registry项，COM信息，快捷方式，文件扩展名，启动条件，GAC安装，ODBC等的合并。
WIX进一步支持SQL Server扩展，IIS安装和configuration，性能计数器，DirectX检查和其他游戏相关任务，.NET本地图像生成，COM +，驱动程序，防火墙规则，PowerShell扩展，应用程序closures，用户，团体，股份等等的pipe理。 有些涉及到处理，但比自己的自定义操作更可靠。
阅读这个Wix快速介绍 ，了解用于编译MSI文件的新的基于XML的方法。 基于文本的源文件比以前提供了更好的源代码控制。 这是一个强烈推荐的免费的开源工具包。 有没有更好的方式来制作MSI文件。
注意 ：在线程中的其他地方可以快速查看MSI文件的常见devise问题 – 这是非常不完整的，但值得一读。 我不想在这个答复中加上这个答案，因为它不是100％相关的，但是对于现实世界的使用来说，这是一个至关重要的话题。
（赦免无耻的“促销” – 这是为了方便访问和检索）
这里只是几个主题的链接，这些链接可能有助于系统pipe理员努力控制其networking上的部署：
推荐的：
特别的操作方法：
debugging：
概念主题/最佳实践：
这个答案是一个正在进行的工作和一个粗略的概述。 增加，问题和更新欢迎。 这份清单绝非详尽无遗。 添加一个有关麻烦包的信息的评论。
我还必须警告，许多MSI文件包含错误，有时是严重错误，但经过培训的应用程序打包程序将能够检测到这种情况，并且在大多数情况下可以消除此问题。 我将其作为一个单独的答案添加，因为它基本上回答了一个不同的问题，但是我觉得它在同一个线程中是相关的。
MSI涉及的技术细节非常复杂 。 在基本级别上，它将文件和registry设置分解为组件（primefaces安装）和function（用户可选的应用程序部件以进行安装，例如字典function）。 有许多最佳实践规则来拆分组件，而且MSI文件中的错误是非常多的。 这些错误通常是通过标准化使用“主要升级”来处理的。
实际的安装是在许多安装顺序中进行的，其中一些安装顺序较高 。 所有这些都是在数据库表中定义的，这就是MSI理解和处理非常复杂的地方。 传播整个安装序列是标准和自定义操作。 标准的行动是微软devise和需要发生（序列有时可以修改）。 自定义操作可供供应商执行自身不涵盖的自定义逻辑。 这些可以是脚本或编译forms。 自定义操作可以立即执行（一次运行，不应该改变系统，但通常是这样做）或延迟（写入执行脚本，然后作为事务执行，因此支持回滚）。
在一个MSI中的典型错误是（没有特定的顺序 – 真正的混乱）：
There are a number of more subtle errors and several larger, typical problems that I will have forgotten.
Check out the Windows Installer Best Practice article from MSDN .
Using MSI's also makes patching (MSP files) and upgrades easier. MSI's use the concept of unique Product and Upgrade codes which makes the whole process easier.
Some deployment systems (CA Unicenter Software Delivery is one example) can also understand MSI's in a special way, which allows them to integrate much better into the deployment system. For example you can feed an MSI into the software library of the deployment system and it will automatically detect the various features within the product and automatically allow much more granular custom actions (Local Install, Verify, Repair etc.) and logging.
Self-heal / repair is also a major plus for MSI's.
Also, check out open source Windows Installer XML , "a toolset that builds Windows installation packages from XML source code. The toolset supports a command line environment that developers may integrate into their build processes to build MSI and MSM setup packages." This is used by MS to prepare several of its major software packages.
you can do transformations – in theory you can customize a lot, if program was packaged properly by vendor you can make fully automated deployment without any interaction with end user – which is very helpful when you want to standardize your windows environment and have more then handful of computers.
to see what people do with msis [ or unattended deployment ] visit for instance this site and it's forums.