更新，2018 年 7 月：stackoverflow 上提供了以下信息的高度压缩摘要：MSI 的主要好处 （"executive summary"- of sorts）。

我曾在开发部门担任过发布经理、构建工程师、设置开发人员以及大公司的应用程序打包人员和部署工程师。

这是对 MSI的最佳（和最差）概念和实际功能的回顾。在 MSI 文件中发现的最常见的设计问题在下面作为单独的答案提供。不假装完整——实际上只是一个凌乱的“大脑垃圾场”——旨在作为“书中找不到的东西”（可能有充分的理由）。

我还想推荐这篇MSDN 文章作为好读物：Windows 安装程序：系统管理员的好处和实施。

标准化：

总而言之，MSI 是关于标准化，是关于处理遗留安装程序技术的“部署气味”。一整套导致重复部署问题的不良安装架构设计。

总体而言，MSI 为安装程序提供了一个全面的标准化框架，其中至关重要的是还包括卸载和内置功能以及通过可远程触发的标准化 GUI进行静默运行的选项。

仅这些功能就构成了对以前处理卸载和静默运行随意的安装技术的巨大改进 - 可能是企业部署的最重要功能以及通过Active Directory或专用远程管理工具（如Microsoft SCCM（以前称为 SMS））进行的可靠远程包管理， IBM Tivoli、 CA Unicenter等。

有人复制了此答案的先前版本。也许更快的阅读？

旧版安装程序“部署气味”

MSI 在设计上积极阻止遗留部署气味。这些主题将在下面的后面部分讨论，但作为一个快速列表，旧安装程序和旧部署技术最容易识别的问题是：

• 1）他们有时会降级并覆盖共享和版本控制的文件，而不太关心导致的dll-hell
• 2)安装程序通常没有提供正确的卸载例程，或者没有正确可靠地完成 - 特别是在静默运行时。这是企业国有企业管理的一个非常大的问题
• 3) 很少正确支持静默安装。可靠性很差，并且经常需要记录带有对话框选择的安装运行，这不能很好地处理意外情况，例如原始运行中未记录的错误对话框或警告对话框
• 4)安装程序没有记录安装的内容，因此没有自动方法来验证磁盘上的文件以检查它们是否仍然是安装程序最初安装的版本
• 5)它们为安装可执行文件提供了不可预测、不可靠和非标准的命令行参数
• 6)由于非标准命令行和缺乏标准，很难以可靠和可预测的方式定制具有企业部署所需的特定值的安装程序
• 7）普通用户无法运行这些安装，并且经常不得不使用临时管理员权限（如果足够的话，使用“运行身份”，或者以管理员身份登录，安装然后注销 - 这种完整的登录和配置文件生成有时需要安装才能完成）
• 8) setup.exe安装程序通常不会返回正确的错误代码或成功代码，有时它会立即退出并启动另一个完成安装的进程，这使得很难确定安装是否完成 - 特别是通过批处理文件
• 9)大多数 setup.exe 文件都允许提取文件，但不能以可靠、可预测的方式进行提取——您通常必须花费大量时间来寻找正确的开关来完成它
• 10)在某些工具中， 日志记录通常很差而且相当随意。使用日志文件进行调试很少能产生清晰性，但确实有所帮助
• 11)安装程序的操作不透明，安装失败后没有或不可靠的回滚以撤消更改
• 12)没有部署共享运行时组件的行业标准方式，无论它们是操作系统组件、第三方组件还是您自己的组件

清单上还有许多其他重要且公认的部署缺陷。显然，在企业部署领域，这些问题最常出现，并导致了“应用程序重新打包”业务，其中使用磁盘和注册表扫描技术捕获旧安装程序，以创建符合标准的 MSI 文件用于可靠部署。

应用程序重新打包是一项专业工作，如果知识渊博的人正确完成，通常会产生质量极佳的 MSI 文件，但由于复杂的注册逻辑必须以交互方式运行才能使某些应用程序正常工作，因此不可能重新打包所有应用程序。

MSI 优势 - 简短摘要

用简单的语言来说，MSI 真正重要的好处是（排名不分先后）：

• 1) 卸载始终可用于每个包，除非它被主动禁用
• 2）这对于logging也是一样的，它很好而且标准化，虽然很冗长（可以使用 WiLogUtl.exe 等工具来分析日志文件）
• 3) MSI 文件的作用在很大程度上是（半）透明或“可检查”的。例外是自定义操作 - （请参阅下面的透明度部分）
• 4）设置定制以标准化的方式完成（转换）
• 5)由于安装是通过 Active Directory 广告、组策略或远程管理提升的，因此无需使用临时管理员权限。这里有一些资格。另请参阅组策略对象编辑器中的此屏幕截图。
• 6)通过管理工具或使用 msiexec.exe 静默安装/卸载效果很好
• 7)对失败的安装有完整的回滚支持。如果您在盒子上手动安装，则需要了解一些资格。
• 8) MSI 文件适用于一致性和逻辑有效性的检查和验证，因为它们符合数据库模式（参见验证示例）
• 9)更新是标准化的类型，虽然对于没有经验的打包者来说很复杂并且经常出错
• 10)从 msi中提取文件是一个内置功能（查看链接文章以获得良好的快速概述）
• 11) Windows Installer 命令行msiexec.exe具有对如何执行安装顺序的非常细粒度的控制，并且所有选项都适用于所有符合标准的 MSI 文件（设置日志级别、静默/交互/半静默运行，设置安装参数，应用变换等...）。
• 12) 合并模块是 MSI 机制，用于传递具有多个 MSI 包的共享文件。它是一个可消耗的模块或安装逻辑包，可在编译时与任何 MSI 包合并。Wix 通过使用 Wix 包含文件扩展和改进了这个概念——我认为这个概念优于合并模块——尤其是对于您自己的文件（即不是操作系统文件）
• 13) Windows 安装程序引擎本身具有防止在安装时覆盖版本化或修改过的文件的机制。这是由相当复杂的文件替换逻辑控制的。虽然高效且良好，但逻辑本身可能最终成为问题，因为许多开发人员在升级时面临无法覆盖修改后的配置文件的问题。这些问题的解决方案通常是对应用程序设计进行微小的更改，以避免常见的部署反模式——尽管这本身就是一个大讨论。

在现实世界中，我发现不太成功的方面包括修补（非常复杂）、MSI-GUI（简单的功能、相当复杂、缺乏灵活性）、弹性（可能导致难以调试重复的自我修复问题）和整体复杂性处理初学者的技术（有时基本操作的高度复杂性 - 例如升级，GUI和许多交互细节会导致意想不到的结果等......）。由于 MSI 的开销增加，安装过程的速度也大大减慢。请参阅一些提高 MSI 安装速度的提示。

文本的其余部分更详细地讨论了 MSI 的这些方面。

透明度（开放式安装程序格式）

MSI 文件本质上是一个精简的SQL-Server 数据库，存储为COM 结构的存储文件- 本质上是文件或数据流集合中的文件系统。这是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等）通过 API 支持 Win32、COM 或 .NET 访问此数据库...

安全性（临时提升的权利）

MSI 还包含“提升权限”原则，允许受限用户触发安装需要管理员权限才能安装的产品。这是“广告功能”的一部分，它允许管理员向用户提供安装程序，而无需在所有工作站上实际安装它们。安装程序本身必须在多个核心帐户上正确创作，此提升权限概念才能正常工作。用户可以自己触发产品的安装，或者安装可能由专用部署系统控制，例如 SCCM、Tivoli、Unicenter（通常是较大的公司）。无需使用临时管理员权限即可正常工作传统安装程序通常是这种情况。

全面的安装数据库还确保您全面了解已安装的补丁程序，因此可以通过自动化和管理工具检测安全漏洞。

验证

可以使用验证规则检查 MSI 文件，以确保它符合许多内部一致性规则（称为ICE）。公司可以创建自己的 ICE 检查来执行特殊的公司规则和要求。这对 QA 有很大帮助。可以进行验证的原因是关系数据库和相关数据库模式的自引用性质。数据库必须在外键、数据类型、字段宽度、模式版本等方面保持内部一致并符合其自己的模式......验证也超越了这一点，并且能够检测包中真正的逻辑缺陷和错误，而不仅仅是格式和类型缺陷。例如，它可以检测部署到错误目标目的地的文件或文件类型。

弹性（自我修复）

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 Installer 团队的Robert Macdonald撰写的这篇文章作为 MSI 日志记录的实用方法： How to Interpret Windows Installer Logs。

结论

Windows Installer 并非一切都好。它的复杂性有时令人费解，但对于大公司而言，如果您考虑到上述好处列表，则 MSI 文件远远优于任何其他形式的部署。

新的安装程序范例（庞大的 SQL 语句）

要理解新的“范式”，重要的是要理解 MSI 旨在作为对目标系统上将发生的事情的声明性描述，而不是固定的事件序列。我想你可以把它想象成一个巨大的 SQL 语句。例如，您将要添加或修改的项目声明到 INI 文件。随着安装的运行，更改会被跟踪并且可以回滚，以便在安装失败时可以恢复更改。这真的像“自动魔法”一样工作，并且在正确完成时是可靠的。

自定义操作（通常的嫌疑人）

对于经验丰富的 MSI 开发人员来说，看到人们依赖复杂、不可靠的自定义操作来获得通过内置 MSI 功能更好地实现的功能，这让经验丰富的 MSI 开发人员感到非常头疼。所有 MSI 错误和回滚问题的很大一部分是由错误的自定义操作引起的，而大多数其他错误是由错误使用 MSI 设计引起的（有关常见 MSI 错误列表，请参阅单独的答案）。

除了内置的 MSI 功能外，越来越多的自定义功能现在可以通过新框架（例如Wix）获得 - 编译 MSI 文件的 XML 方式，因此大多数操作对复杂的自定义操作逻辑的需求越来越少。

MSI完全支持处理 ini 文件设置、字体、环境变量、注册表项、COM 信息、快捷方式、文件扩展名、启动条件、GAC 安装、ODBC 等的合并...

WIX进一步支持非常高级的功能，例如 SQL 服务器扩展、IIS 安装和配置、性能计数器、DirectX 检查和其他游戏相关任务、.NET 本机图像生成、COM+、驱动程序、防火墙规则、PowerShell 扩展、应用程序关闭、管理用户、组、共享等等。处理起来有些复杂，但比您自己的自定义操作更可靠。

如果可能，不惜一切代价避免自定义操作

换个角度来看：这些内置和现成的解决方案是由可用的最好的部署专家制作的，并且经过数千、数万甚至数百万用户的测试（对于 MSI 中的内置内容）本身）。您真的认为自己可以做得更好吗？ 使用自定义操作应该很少见，并且绝对有必要为您安装的产品实现独特的功能。而且您还必须编写适当的回滚支持，这是相当复杂的。

编写自定义操作几乎总是一个错误，但也有真正需要灵活性的情况。与往常一样，选择好你的战斗很重要。一开始这可能是一项有趣的任务，但您可能会面临许多意想不到的问题并浪费大量宝贵的时间。我的意思是非常严肃的。我自己编写了一套 C++ 自定义操作供企业使用（以消除容易出错的 VBScript 自定义操作）——这不是在公园里散步，虽然编码可能不是世界上最困难的，但调试和测试和连接到实际的 MSI 文件是非常复杂的。花点时间研究一下可用的现成选项可能会为您节省数周的开发工作，并产生更高的部署可靠性。

使用应用程序启动序列

非常重要的一点是，当您有可预测的运行时上下文和良好的错误处理可用时，应该在应用程序启动时进行大量应用程序配置，而不是在只运行一次且具有非常复杂的模拟、排序、调节和运行时的设置中复杂性。

您的设置不应该配置应用程序，它应该在首次启动时准备应用程序进行配置。具体来说，您的设置应该编写所有需要提升权限的设置- 写入 HKLM、注册服务、安装到每台机器的路径以及应用程序无法使用常规用户权限自行编写的任何此类内容。

如果您是设置开发人员，您应该提供参与编写应用程序启动序列的代码，而不是编写设置自定义操作。如果不出意外，为了避免看起来你试图“推卸责任”给别人。在这个启动序列中，您可以编写更可靠和可测试的代码，这些代码更容易从 QA 人员那里获得帮助进行测试（他们通常不了解部署测试和应用程序测试）。

设置复杂性

设置复杂性的核心围绕以下事实：错误是累积的（您正在管理交付过程，而不仅仅是快速重新编译），错误很难调试（无法访问发生错误的系统）以及目标系统州在几乎所有可以想象的方式上都不同。请参阅此答案以更深入地讨论这种复杂性以及目标系统如何以令人震惊的方式保持警惕：Windows Installer 和 WiX 的创建，以及部署的复杂性（见底部）。

WiX（某些用途的最佳 MSI 解决方案）

阅读此WiX 快速介绍，了解基于 XML 的新方法来编译 MSI 文件的说明。基于文本的源文件提供了比以前更好的源代码控制。这是一个免费的开源工具包，强烈推荐。

注意：请参阅线程中的其他地方以快速了解 MSI 文件的常见设计问题- 它非常不完整，但值得一读。我不想将其添加到此回复中，因为它不是 100% 相关的，但对于现实世界的使用，它是一个至关重要的话题。

系统管理员的一些核心 MSI 信息：

（请原谅无耻的“促销” - 这是为了方便访问和检索）

以下只是一些主题链接，这些链接可能有助于系统管理员控制其网络上的部署：

• 如何消除 C:\Windows\Installer 中巨大的缓存 MSI 文件？（MSI 磁盘使用率高）
• 如何加快 MSI 安装（只有几个选项）
• 如何从 setup.exe 中提取文件（值得任何管理员阅读，可能是旧消息）
• 卸载 MSI 的不同方法（卸载参考，流行- 大量浏览）
• 处理 MSI 包时如何绕过 msiexec.exe（MSI 自动化和脚本）
• 为什么 MSI 需要原始 .msi 文件才能继续卸载？（常见问题）
• 为什么安装时进程列表中有多个msiexec.exe进程？他们都在做什么？

特殊操作方法主题：

• 强制升级在初始安装期间修改的文件（常见问题）
• 无论如何让 msiexec 回显到标准输出而不是记录到文件（高级主题，使用 MSI 的外部 gui，更多开发人员内容）
• 我想安装 MSI 两次（实例转换或虚拟化 - 认真 :-)）。
• 如何使用 ActiveSetup 更新每个用户配置文件（有点危险，但很有用）
• MSI 包中的常见错误（更多针对开发人员，也针对系统管理员）
• 如何调试周期性自修复（重要课题）

概念主题/最佳实践：

• 程序安装的好处和真正目的是什么？（部署基础）
• 管理安装的目的（系统管理员的核心 MSI 操作）
• 为什么不应该使用 MSI 进行注册表调整（推荐阅读）
• 使用什么安装产品？（不同工具的优缺点）
• 为什么自注册在 MSI 中被认为是有害的

只是几个好处：

• 可以做广告（以便按需安装）。
• 就像广告一样，功能可以在用户尝试使用它们时立即安装。
• 状态管理得到维护，因此 Windows Installer 提供了一种让管理员查看应用程序是否安装在计算机上的方法。
• 如果安装失败，则能够回滚。

我想当我在企业环境中部署软件时：通过 MSI 部署软件几乎是一种享受。相比之下，我几乎总是害怕在另一个容器中部署软件。

有关操作 MSI 安装的其他信息，msiexec请在“运行”对话框中键入。

这个答案在很大程度上是一项正在进行的工作和一个粗略的大纲。欢迎补充，问题和更新。这份清单绝不是详尽无遗的。添加有关麻烦包的信息的评论。

MSI封装中的典型问题和设计缺陷

我还必须警告说，许多 MSI 文件包含错误，有时甚至是严重错误，但经过培训的应用程序打包人员将能够检测到这一点，并在大多数情况下消除问题。我将此添加为单独的答案，因为它本质上回答了一个不同的问题，但我觉得它在同一个线程中是相关的。

MSI涉及的技术细节非常复杂。在基本层面上，它是将您的文件和注册表设置分解为组件（原子安装）和功能（用户可选择安装的应用程序部分，例如字典功能）。有许多拆分组件的最佳实践规则，这里的 MSI 文件中的错误很多。这些错误通常通过标准化“重大升级”的使用来处理。

实际安装是按多个安装顺序执行的，其中一些具有提升的权限。所有这些东西都在数据库表中定义，这就是 MSI 难以理解和处理的地方。在整个安装序列中传播的是标准和自定义操作。标准操作是 Microsoft 设计的，需要执行（有时可以修改顺序）。供应商可以使用自定义操作来执行 MSI 本身未涵盖的自定义逻辑。这些可以是脚本或编译形式。自定义操作可以是立即的（立即运行，不应该改变系统，但经常这样做）或延迟（写入一个执行脚本，然后作为事务执行，因此支持回滚）。

MSI 中的典型错误是（没有特别的顺序 - 并且确实呈现为真正的混乱）：

• 组件创建错误（未遵循最佳实践）。这可能会导致补丁和升级出现问题，并出现神秘症状，例如丢失文件和设置或因无意义错误而崩溃的补丁。为了过度简化，除非文件数量巨大，否则每个组件应该使用一个文件。
• 与用户数据被覆盖或重置有关的升级问题。请参阅下面的更多详细信息。
• 在安装顺序的“已处理部分”之外的自定义操作的错误调度或错误类型的自定义操作放置不正确。当通过部署系统远程运行时，这通常会导致操作失败（没有提升的权限），并且回滚会被有效地削弱，因为只有事务操作会被回滚。Windows Installer 事务（想想数据库事务提交）在主安装序列中的标准操作InstallInitialize和InstallFinalize之间运行，并以提升的权限运行。系统的所有更改都将在此事务中发生 - 其他任何事情都是错误的（但不幸的是很常见）。
• 使用即时模式自定义操作在事务安装序列之外对系统进行更改。这会破坏回滚支持，并且通常会触发安全错误，因为即时模式自定义操作不会以提升的用户权限运行，无论它们位于安装序列中的哪个位置。
• 错误的设计会导致无明显原因的重复循环自我修复。这是来自 installsite.org 的另一篇关于此主题的文章
• 在无人值守安装模式下不遵守 GUI 抑制的自定义操作可能会显示模式对话框，从而在静默运行时导致部署完全失败。此问题以及静默模式和交互模式之间的总体差异在此处进行了更详细的描述（有些冗长和冗长）：从控制面板卸载不同于从 .msi 中删除
• 错误编写的包中的一些自定义操作仅插入到用户界面序列中。这会导致它们不能在静默安装模式下运行。这对于企业部署来说是很严重的，因为这里几乎只使用静默安装。此问题也会影响卸载，这意味着您可能必须以交互方式运行卸载才能进行卸载，以确保所有清理自定义操作都运行。同样，有关用户界面级别的详细说明，请参见上一个要点中的链接。
• 安装程序包含不打算部署在它们要安装到的位置的文件。通常应在 winsxs 程序集文件夹中并排安装的系统文件。
• 安装速度慢是许多 MSI 报告的另一个“问题”。以下是有关该主题的一些提示。总体而言，Windows Installer 具有相当多的开销，因为注册表中对正在安装的内容的注册要求很高。
• 覆盖定制信息或共享数据文件。例如，如果 INI 文件是通过 File 表而不是 IniFile 表安装的，则会发生这种情况。在后一种情况下，它被视为“更改事务”，在前一种情况下，它是文件替换操作，这通常是错误的，除非您的 INI 文件具有非标准格式或您希望与文件一起部署的大型注释部分（在某些情况下很常见）开发者工具）。
• 文件覆盖的复杂规则可能会导致文件被无意覆盖或根本不更新 - 这是一个典型的 MSI 问题。查看这篇文章，了解如何强制覆盖不会升级的文件。这些规则可以通过在 msiexec.exe 命令行级别设置的REINSTALLMODE 属性的自定义设置进行微调（覆盖旧版本、覆盖相同版本、覆盖任何版本等），并且它们对数据文件和版本文件的工作方式不同。SDK 中的详细信息。理解这一点至关重要，即使理解了，这种设计也常常令人不悦。
• 在安装过程中自行注册 COM 文件可能会触发安全警告或以各种方式导致问题。查看这篇文章：自我注册被认为有害。
• 文件替换问题的一个变体是重大升级（卸载并重新安装产品）卸载修改的文件并重新安装默认版本的情况。在这些情况下，内容看起来被还原或覆盖，而实际上它是先卸载然后重新安装的。
• 使用自定义用户凭据运行的服务可能会在主要升级方案期间丢失其凭据，并且设置文件（似乎）恢复为默认值（它们实际上已被卸载并重新安装）。仅作记录：在我看来，使用用户凭据运行的服务首先是一个设计缺陷。
• 公共属性未从客户端正确传递到服务器进程，从而导致自定义操作无法按预期完成。这涉及更新 SecureCustomActionProperties 属性。
• 某些应用程序无法为最初安装该设置的用户以外的其他用户正常运行。这是一个严重的设计错误，但通常可以由经验丰富的应用程序打包者使用自我修复或 ActiveSetup添加HKCU 注册表项和用户配置文件来修复。这是一个相当复杂的主题，可能需要一些黑魔法才能开始工作。记录在案：在我看来，真正的解决方案是更改应用程序本身，以便能够根据从每台计算机位置复制的默认设置和模板或基于应用程序内部默认值（从源代码）。
• 一些 MSI 文件通过在这里、那里和任何地方为非管理员设置完整的读/写权限来破坏已安装文件的安全性。其他时候，由于缺少权限，应用程序会停止在较新版本的 Windows 上运行。应用程序打包者经常面临对应用程序自定义权限需求的分析。通常在 HKLM 或 %ProgramFiles% 的某个地方需要一些额外的权限
• 过去的一些Installshield设置会在安装过程中尝试连接到 Internet。这对于部署受到严格控制的企业部署场景来说是可怕的，并且安装程序永远不会被允许直接从 Internet 下载新内容。
• 另一个网络问题是当设置试图显示一个 GUI 时，人们可以在其中输入在安装时通过 Internet 验证的数据，或者只是显示来自其网站的实时内容。这通常是电子邮件地址、联系信息、许可证密钥等。连接完全失败的原因有很多，通常是由于企业环境中缺少代理配置（没有直接连接到 Internet，所有 Internet 流量都通过特定的缓存服务器路由，每个进程都需要提供凭据才能通过防火墙） . 这是一篇关于通过设置验证许可证的风险的文章。
• Installshield用于为其Installscript语言安装运行时。这个先决条件设置通常包含在 setup.exe 中，它是传说中的问题根源。有很多版本，一些不兼容的地方，以及过去经常发生的一些运行时错误。自版本 12（或更高版本）以来，此运行时现在已可靠安装，并且它正在以可靠的方式编译为本机或运行沙盒（我不确定哪个，一个或另一个 - 可能是沙盒）。不过，较旧的 Installshield 设置可能会显示此部署问题。Installshield 有一个旧版支持站点，用于解决以下问题：http ://consumer.installshield.com/common.asp
• 在设置为英语以外的其他语言的机器上运行时，甚至当您在英语机器上运行本地化（翻译）版本的设置时，一些设置可能会显示不稳定的安装行为或间歇性错误。这可能是纯粹的运行时故障，或者本地化对话框具有截断文本或格式错误或翻译错误或与语言本地化相关的许多其他类型的错误的情况- 整个专业领域（翻译图像中的文本、翻译软件本身、翻译营销材料、处理国际支持请求、适应操作系统中的语言设置等......）。一些语言需要改变整个应用程序来解决它们的语言特性——典型的问题是字符串宏和代码页设置，后者在引入 Unicode 时问题不大。查看翻译工具的示例屏幕截图。
• 几乎所有设置都未能通过可用于测试 MSI 软件包质量的几个内置验证测试。有关验证的实际示例，请参阅本文。
• 有时，MSI 的升级会失败，因为在主要升级扫描期间实际上只检查了 MSI 版本号的 3 位数字。
• INI 文件的安装是 Windows Installer 的内置功能。可以以任何需要的方式添加、删除、合并或处理条目。但是，INI 文件作为文件而不是分段值安装是很常见的。这可能会导致 INI 文件在重新安装期间被覆盖，而不是被更新。一个非常常见的 MSI 问题。
• 上述问题也适用于 .NET 应用程序及其 Config.xml 文件。在这种情况下，MSI 没有内置方式来详细更新内容，您需要通过自定义操作对更新进行编码或在安装时替换整个文件。Wix 可能为此提供了新功能，但 Windows Installer 引擎没有内置此功能。

还有一些更微妙的错误和几个更大的典型问题，我会忘记的。

查看MSDN中的Windows Installer 最佳实践文章。

使用 MSI 还可以更轻松地进行修补（MSP 文件）和升级。MSI 使用独特的产品和升级代码的概念，使整个过程更容易。

一些部署系统（CA Unicenter Software Delivery 就是一个例子）也可以以一种特殊的方式理解 MSI，这使它们能够更好地集成到部署系统中。例如，您可以将 MSI 输入部署系统的软件库，它会自动检测产品中的各种功能并自动允许更精细的自定义操作（本地安装、验证、修复等）和日志记录。

自我修复/修复也是微星的一大优势。

此外，请查看开源Windows Installer XML，“一个从 XML 源代码构建 Windows 安装包的工具集。该工具集支持命令行环境，开发人员可以将其集成到他们的构建过程中以构建 MSI 和 MSM 安装包。” MS 使用它来准备几个主要的软件包。

您可以进行转换-理论上您可以自定义很多，如果程序由供应商正确打包，您可以在不与最终用户进行任何交互的情况下进行完全自动化的部署-当您想要标准化您的 Windows 环境并拥有更多时，这非常有用的计算机。

要查看人们对 msis [或无人值守部署] 所做的事情，请访问例如此站点及其论坛。