与常规setup.exe文件相比，使用.msi文件有什么优点？
我的印象是，在用户权限很少但不确定细节的机器上，部署更容易。
与使用setup.exe方案相比，msiexec.exe具有哪些功能使部署更容易？
部署.msi应用程序时有任何提示或技巧吗？
与常规setup.exe文件相比，使用.msi文件有什么优点？
我的印象是，在用户权限很少但不确定细节的机器上，部署更容易。
与使用setup.exe方案相比，msiexec.exe具有哪些功能使部署更容易？
部署.msi应用程序时有任何提示或技巧吗？
Answers:
仅有的一些好处：
我想当我在企业环境中部署软件时：通过MSI部署软件几乎很有趣。相比之下，当它在另一个容器中时，我几乎总是发现自己讨厌部署软件。
有关操作MSI安装的其他信息，请msiexec在“运行”对话框中键入。
更新，2018年7月：以下有关堆栈溢出的信息的压缩非常摘要：MSI的主要优点 （"executive summary"-种类）。
我曾在开发部门担任过发行经理，构建工程师，设置开发人员以及大型公司的应用程序打包程序和部署工程师。
这是对MSI 最佳（和最差）概念和实际功能的评论。MSI文件中发现的最常见的设计问题在下面作为单独的答案给出。不假装不完整-实际上只是一个凌乱的“脑垃圾场”-旨在作为“书中找不到的东西”（可能是有充分的理由）。
我也想建议这篇MSDN文章作为一本好书：Windows Installer：系统管理员的好处和实现。
简而言之，MSI与标准化有关，与处理传统安装程序技术的“ 部署气味 ”有关。一整套不良的安装体系结构设计，这些问题导致重复的部署问题。
总体而言，MSI为安装程序提供了一个全面，标准化的框架，并且至关重要的是，该框架还包括卸载和内置功能以及用于通过标准GUI进行静默运行的选项，这些GUI可以远程触发。
仅这些功能就构成了对以前的安装技术的重大改进，这些安装技术可以随意处理卸载和静默运行-可能是企业部署中最重要的功能，以及通过 Active Directory或专用远程管理工具（例如 Microsoft SCCM（以前称为SMS））进行可靠的远程软件包管理， IBM Tivoli， CA Unicenter和类似的产品。
有人重复了此答案的先前版本。也许更快阅读？
MSI 通过设计积极地阻止了传统部署的气味。这些主题将在下面的后续部分中进行讨论，但以快速列表的形式列出了传统安装程序和较旧的部署技术中最可识别的问题：
该列表还包含许多其他关键的和公认的部署缺陷。显然，在企业部署领域中，这些问题最经常出现，并且导致了“ 应用程序重新打包 ” 业务，在该业务中，使用磁盘和注册表扫描技术捕获了旧的安装程序，从而创建了符合标准的MSI文件进行可靠的部署。
应用程序重新打包是一项专业的工作，如果由有经验的人员正确完成，通常会产生高质量的MSI文件，但是由于必须交互运行某些应用程序才能运行的复杂注册逻辑，因此无法重新打包所有应用程序。
用简单的语言来说，MSI真正重要的好处是（无特定顺序）：
在现实世界中，我发现不太成功的方面包括打补丁（非常复杂），MSI-GUI（简单功能，非常复杂，缺乏灵活性），弹性（可能会导致难以调试的重复自我修复问题）以及整体复杂性为初学者处理该技术的知识（有时基本操作的复杂性很高，例如升级，GUI和许多交互的细节会导致意外的结果等）。由于MSI开销的增加，安装过程的速度也大大降低了。请参阅一些有关提高MSI安装速度的提示。
本文的其余部分将更详细地介绍MSI的某些方面。
MSI文件本质上是作为COM结构存储文件存储的精简SQL Server数据库 -本质上是文件或数据流集合中的文件系统。这是Microsoft Office文档中使用的文件类型，它产生了一种可以检查和检查的标准格式 - 对于大公司而言，这是一个巨大的问题。
除了已编译的自定义操作，MSI文件是一个白框。如果安装程序更改了某些疯狂的事情，例如系统范围的网络设置，则实际上可以使用适当的工具查看它。值得注意的例外是已编译的自定义操作 - 黑盒。Windows徽标要求要求对自定义操作进行注释，以说明它们在做什么，但是安装开发人员通常会忽略此操作。希望Wix的出现将改善这一点。
为了确定这种已编译的自定义操作实际上在技术上的作用，必须进行设置捕获。根据我的经验，这几乎是没有做到的。如果软件需要公司部署批准，通常会联系供应商以获取信息，然后可能是阻止其使用的应用程序本身，而不仅仅是安装程序。
可以通过转换来定制MSI，以适应组织的需求和标准，同时仍允许与供应商的安装程序更新互操作。您无需更改安装程序本身，而是在称为组织转换（.mst文件）的单独组织特定文件中创建自定义项（数据库片段或根据需要更改事务）。您可以随意禁用自定义操作，并且通常可以更改，覆盖或禁用安装程序中的任何内容，甚至可以添加新内容，包括文件。有时，转换文件也用于将MSI文件本地化为不同的语言。可以将多个转换应用于单个MSI，这是具有截断路径的示例：
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 Installer会维护一个完整的数据库，其中包含产品已在注册表中安装的所有项目（HKEY_CLASSES_ROOT \ Installer-切勿直接在此处进行任何更改！这对于专家也是如此）。
您可以可靠地确定是否安装了产品，安装了哪些功能以及安装了什么文件版本。此外，您还可以获得所有已应用于基本产品的补丁程序的列表。您可以使用各种脚本，配置和管理工具（例如Microsoft SCCM，IBM Tivoli，CA Unicenter等）通过支持Win32，COM或.NET的API来访问此数据库。
MSI还包含“高权限”原则，该原则允许受限制的用户触发需要管理员权限才能安装的产品的安装。这是“ 广告功能 ”的一部分，该功能使管理员可以将安装程序提供给用户，而无需实际在所有工作站上安装它们。必须在多个核心帐户上正确编写安装程序本身，此高权限概念才能正常运行。用户可以自己触发产品的安装，也可以由专用部署系统（例如SCCM，Tivoli，Unicenter（通常是大型公司））控制安装。无需弄乱临时管理员权限即可使工作正常进行 旧版安装程序通常就是这种情况。
全面的安装数据库还可以确保您全面了解已安装的修补程序，因此可以通过自动化和管理工具检测安全漏洞。
可以使用验证规则检查MSI文件，以确保它符合许多内部一致性规则（称为ICE））。公司可以创建自己的ICE检查以执行特殊的公司规则和要求。这对质量检查有很大帮助。之所以可以进行验证，是因为关系数据库和关联的数据库模式具有自引用特性。数据库必须在内部保持一致，并在外键，数据类型，字段宽度，模式版本等方面符合其自身的模式。验证也不仅限于此，还能够检测软件包中真正的逻辑缺陷和错误。 ，而不仅仅是格式和类型缺陷。例如，它可以检测正在部署到错误目标位置的文件或文件类型。
Windows安装程序的管理员安装功能提供了一种从MSI提取源文件的标准方法（这是有关此主题的一些其他信息）。然后可以将这些源文件放在共享上，并可供所有工作站安装。这样可确保完成修复，卸载和修改操作，而无需请求CD或类似介质上的安装介质。对于修补和更新操作（在特殊情况下可能需要访问旧版本的源文件）而言，这尤其重要。
此弹性功能还存在一些常见问题。大多数管理员都有经验丰富的计算机，它们具有周期性的自我修复周期，而且似乎从未停止过。单击链接以获取此问题的长原因列表。同样，这是一个较短的版本，可能更易于阅读。
MSI文件的安装通常会触发还原点的创建。此外，如果安装无法完成，则所有在安装期间替换或覆盖的文件和注册表项都将被保存和恢复，除非在自定义操作中进行了任何更改。
自定义操作必须实现自己的对Windows徽标合规性的回滚支持。这通常被忽略，但是涉及创建第二个自定义操作以撤消主自定义操作所做的更改。
回滚可确保即使安装失败，工作站也可以保持稳定状态。在实际的回滚脚本保存在一个隐藏文件夹直接在系统驱动器上-一般是C：\ Config.MSI，它包含与扩展.RBS和.RBF文件- 回滚脚本文件。如您所料，设计不当的MSI文件可能会违反此处的Windows内置功能，有关更多详细信息，请参见本主题的其他文章。
有一些方法可以禁用回滚并加快安装速度。一般不建议使用，但是这里是MSIFASTINSTALL属性和DISABLEROLLBACK的详细信息。这是一个复杂的功能，但是这里是快速回滚概述。
尽管非常复杂，但是Windows安装程序中的修补程序已在系统中进行了完全管理和注册，因此可以通过检查已安装的内容来确定系统的安全状态。更新被标准化为一些基本的变体，并且只要您能够处理所涉及的复杂性，就可以以更高的确定性执行更新。部署系统将能够报告哪些更新失败以及原因。
从主观角度来看，修补程序对于2种基本用途非常有效：1）所交付产品的小补丁，以及2）修补已安装产品以修复其错误的卸载顺序，从而阻止了产品的干净卸载。
补丁程序只是用于已经生效的更新的交付机制。因此，它仅仅是一个容器，它更加复杂，而且容易出错比原来的设置本身。修补程序的首要原则是必须小于原始MSI，否则根本没有明显的理由提供修补程序。如果补丁程序针对多个产品版本，则补丁程序可能会迅速变得庞大。
Windows Installer提供了标准化的日志记录功能，该功能大大优于以前的版本，尽管过于冗长。可以使用日志分析器解密日志文件，并且可以使用自定义日志级别来消除生成带有不必要信息的太大日志文件。出于调试目的，详细日志记录非常有用。请参阅Rob Mensching的博客，以获取一种手动读取MSI日志文件的好方法（实际上，您在日志文件中搜索“ value 3 ”）。这是执行详细日志记录的示例命令行：
msiexec.exe /I "C:\Installer.msi" /QN /L*V "C:\msilog.log"
从这篇文章罗伯特·麦克唐纳从Windows安装团队强烈建议作为MSI日志记录实际的样子：如何解读Windows安装程序日志。
并非Windows Installer的所有优点都可以。它的复杂性有时会令人困惑，但是考虑到上述好处，对于大型公司而言，MSI文件比任何其他形式的部署都优越得多。
要理解新的“ 范式 ”，重要的是要理解MSI旨在作为对目标系统上将要发生的事情的声明性描述，而不是固定的事件序列。我想您可以将其视为一个庞大的SQL语句。例如，您声明要添加或修改到INI文件的项目。在安装过程中，将跟踪更改并提供回滚功能，以便在安装失败时可以还原更改。这确实像“ automagic ” 一样工作，并且在正确完成时是可靠的。
这是一个巨大的头疼的经历MSI开发商看到人们依靠复杂的，更符合实施了功能不可靠的自定义操作内建MSI功能。所有MSI错误和回滚问题中有很大一部分是由错误的自定义操作引起的，而大多数其他错误是由MSI设计的错误使用引起的（有关常见MSI错误的列表，请参阅单独的答案）。
除了内置的MSI功能，现在还可以通过新框架（例如Wix）来使用越来越多的自定义功能，Wix是一种用于编译MSI文件的XML方式，因此大多数操作对复杂的自定义动作逻辑的需求越来越少。
MSI完全支持处理ini文件设置，字体，环境变量，注册表项，COM信息，快捷方式，文件扩展名，启动条件，GAC安装，ODBC等的合并。
WIX进一步支持非常高级的功能，例如SQL Server扩展，IIS安装和配置，性能计数器，DirectX检查和其他与游戏相关的任务，.NET本机映像生成，COM +，驱动程序，防火墙规则，PowerShell扩展，应用程序关闭，用户，组，共享等的管理。涉及到一些处理，但是比您自己的自定义操作可靠得多。
试着看待这些问题：这些内置的和现成的解决方案是由可用的最佳部署专家制作的，并且已经过成千上万，甚至数百万个用户的测试（对于MSI中的内置组件）本身）。您是否真的认为可以做一些更好的自定义操作？ 使用自定义动作应该很少见，并且绝对有必要实现所安装产品的独特功能。而且，您还必须编写适当的回滚支持，这非常复杂。
编写自定义动作几乎总是一个错误，但是在某些情况下，您确实也需要灵活性。一如既往，重要的是要做好战斗。刚开始时这可能是一个有趣的任务，但是您可能会面临许多意外问题并浪费大量的时间。我的意思是非常认真的。我自己编写了一套供企业使用的C ++定制操作（以消除容易出错的VBScript定制操作）-无需走动，尽管编码可能并不是世界上最困难的，但调试和测试以及连接到实际的MSI文件非常容易。花费一些时间研究可用的现成选项可能会节省您数周的开发工作，并提高部署可靠性。
非常重要的一点是，当您具有可预测的运行时上下文和良好的错误处理时，应在应用程序启动时进行许多应用程序配置，而不能在仅运行一次且具有非常复杂的模拟，排序，调节和运行时功能的设置中进行配置复杂性。
您的设置不应配置应用程序，而应在首次启动时准备好要配置的应用程序。具体来说，您的设置应写入所有需要提升权限的设置 -写入HKLM，注册服务，安装到每机器路径以及应用程序无法使用常规用户权限自行写入的所有此类内容。
如果您是安装开发人员，则应该提供参与编码应用程序启动顺序的知识，而不是编写安装自定义操作。如果没有别的，为了避免看起来像您在试图“推卸责任”给别人。在此启动序列中，您可以编写更加可靠和可测试的代码，这些代码更容易从质量检查人员那里获得测试的帮助（他们通常不了解部署测试以及应用程序测试）。
设置复杂性的核心在于以下事实：错误是累积性的（您正在管理交付过程，而不仅仅是快速重新编译），错误很难调试（无法访问发生错误的系统）和目标系统。州在几乎可以想象的各个方面都有不同。请参阅此答案，以更全面地讨论这种复杂性以及目标系统可能如何以令人震惊的多种方式进行警惕：Windows Installer和WiX的创建以及“部署的复杂性”（请参阅底部）。
阅读此WiX快速介绍，以描述基于XML的新MSI文件编译方法。基于文本的源文件提供了比以前更好的源代码控制。这是一个强烈推荐的免费开源工具包。
注意：请参见线程中的其他内容，以快速了解MSI文件的常见设计问题 -它非常不完整，但值得一读。我不想在答复中添加该内容，因为它与100％无关，但是对于现实世界而言，这是一个至关重要的话题。
（请原谅无耻的“促销”-以便于访问和检索）
以下是一些指向主题的链接，这些链接可能对系统管理员控制网络部署的工作有所帮助：
特别的操作方法主题：
概念主题/最佳实践：
这个答案很大程度上是一个正在进行的工作，并且是一个粗略的概述。欢迎添加，问题和更新。此列表绝不是详尽无遗的。添加有关麻烦软件包信息的注释。
我还必须警告许多MSI文件包含错误，有时甚至是严重的错误，但是受过训练的应用程序打包程序将能够检测到此错误，并且在大多数情况下，可以消除此问题。我将其添加为单独的答案，因为它本质上回答了一个不同的问题，但是我认为它在同一线程中是相关的。
MSI中涉及的技术细节非常复杂。从根本上讲，它是关于将文件和注册表设置分解为组件（原子安装）和功能（用户可选的要安装的应用程序部件，例如词典功能）。有许多用于拆分组件的最佳实践规则，并且此处的MSI文件中的错误很多。这些错误通常通过标准化“重大升级”的使用来处理。
实际安装按许多安装顺序执行，有些安装顺序具有较高的权限。所有这些事情都是在数据库表中定义的，而这正是MSI难以理解和处理的地方。贯穿安装顺序的是标准操作和自定义操作。这些标准动作是Microsoft设计的，需要执行（有时可以更改顺序）。供应商可以使用自定义操作来执行MSI本身未涵盖的自定义逻辑。这些可以是脚本形式也可以是编译形式。自定义操作可以是立即的（立即运行，不应更改系统，但经常会更改）或推迟（写入执行脚本，然后将其作为事务执行，从而支持回滚）。
MSI中的典型错误是（没有特定的顺序，并且实际上是一团糟）：
我会忘记许多更细微的错误和一些较大的典型问题。
请查阅MSDN上的Windows Installer最佳实践文章。
使用MSI还可以使修补（MSP文件）和升级变得更加容易。MSI使用独特的产品和升级代码的概念，这使整个过程更加容易。
某些部署系统（CA Unicenter Software Delivery是一个示例）也可以以特殊的方式理解MSI，这使它们可以更好地集成到部署系统中。例如，您可以将MSI馈送到部署系统的软件库中，它将自动检测产品中的各种功能，并自动允许进行更精细的自定义操作（本地安装，验证，修复等）并进行日志记录。
自修复/修复也是MSI的一大优势。
另外，请查看开放源代码Windows Installer XML，它是“一个从XML源代码构建Windows安装程序包的工具集。该工具集支持命令行环境，开发人员可以将其集成到其构建过程中以构建MSI和MSM安装程序包。” MS使用它来准备其几个主要软件包。