使用 MSI 文件的企业优势

Question

与常规 setup.exe 文件相比，使用 .msi 文件有哪些优势？

我的印象是在用户权限很少的机器上部署更容易，但不确定细节。

msiexec.exe 有哪些功能使部署比使用 setup.exe 方案更容易？

部署 .msi 应用程序时有什么提示或技巧吗？

Answer 1

更新，2018 年 7 月：stackoverflow 上提供了以下信息的极其压缩的摘要：MSI 的主要优点 （"executive summary"各种）。

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

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

我还想推荐这篇MSDN 文章作为一个很好的阅读：Windows Installer: Benefits and Implementation for System Administrators。

标准化：

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

总体微星提供了一个全面的，标准化的框架，用于安装程序，其中关键的是还包括卸载和内置功能和选项静音运行与标准化GUI可以远程触发。

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

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

遗留安装程序“部署气味”

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

• 1）他们有时会降级和覆盖共享和版本的文件与小的关注DLL地狱是导致
• 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 - 切勿直接更改此处的任何内容！专家也一样）。

您可以可靠地确定是否安装了产品、安装了哪些功能以及安装了哪些文件版本。此外，您可以获得已应用于基本产品的任何补丁的列表（如果有）。您可以通过支持 Win32、COM 或 .NET 的 API使用各种脚本、配置和管理工具（例如Microsoft SCCM、IBM Tivoli、CA Unicenter等）访问此数据库...

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

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

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

验证

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

弹性（自修复）

Windows 安装程序的管理员安装功能提供了一种从 MSI 中提取源文件的标准方法（这里是有关此主题的一些附加信息）。然后可以将这些源文件放在共享上并可供所有工作站使用以进行安装。这可确保修复、卸载和修改操作完成，而无需请求 CD 或类似物上的安装介质。这对于在特殊情况下可能需要访问旧版本源文件的修补和更新操作尤其重要。

此弹性功能也存在常见问题。大多数管理员都经历过机器具有似乎永远不会停止的周期性自我修复周期。按照链接查看此问题的一长串原因。再说一次，这是一个更短的版本，可能更容易阅读。

回滚

MSI 文件的安装通常会触发还原点的创建。此外，如果安装未能完成，所有在安装过程中替换或覆盖的文件和注册表项都将被保存和恢复，除非在自定义操作中进行任何更改。

自定义操作必须为 Windows 徽标合规性实现自己的回滚支持。这通常被忽略，但涉及创建第二个自定义操作以撤消主自定义操作所做的更改。

回滚确保工作站保持稳定状态，即使安装失败。在实际的回滚脚本保存在一个隐藏文件夹，直接在系统驱动器上-一般是C：\ Config.MSI，它包含与扩展.RBS和.RBF文件-回滚脚本文件。正如您可能预期设计不佳的 MSI 文件可能会违反 Windows 的内置功能，请参阅我在此线程中的另一篇文章了解更多详细信息。

有多种方法可以禁用回滚并加快安装速度。通常不推荐使用，但这里有关于 MSIFASTINSTALL 属性和 DISABLEROLLBACK 的详细信息。这是一个复杂的功能，但这里有一个快速回滚概述。

修补和更新

尽管非常复杂，但 Windows 安装程序中的修补程序是在系统上完全管理和注册的，因此可以通过检查已安装的内容来确定系统安全状态。更新被标准化为几个基本变体，这允许以更高的确定性执行更新，前提是您能够处理所涉及的复杂性。部署系统将能够报告哪些更新失败以及原因。

从主观角度来看，修补有两种基本用途：1 ) 交付产品的小修补程序，以及2 ) 修补已安装的产品以修复其错误的卸载顺序，从而阻止产品完全卸载。

补丁只是已经在运行的更新的一种传送机制。因此，它只是一个比原始设置本身更复杂和更容易出错的容器。补丁的首要规则是它必须小于原始 MSI，否则根本没有明显的理由来提供补丁。如果一个补丁针对多个产品版本，它会很快变得庞大。

日志记录（确实详细）

Windows Installer 提供了一个标准化的日志记录功能，虽然几乎过于冗长，但它比以前的版本大大优越。可以使用日志分析器破译日志文件，并且可以使用自定义日志级别来避免生成包含不必要信息的过大日志文件。出于调试目的，详细日志记录非常有用。有关读取 MSI 日志文件的良好手动方法，请参阅Rob Mensching 的博客（实际上，您在日志文件中搜索“值 3 ”）。这是一个执行详细日志记录的示例命令行：

msiexec.exe /I "C:\Installer.msi" /QN /L*V "C:\msilog.log"

从这篇文章罗伯特·麦克唐纳从Windows安装团队强烈建议作为MSI日志记录实际的样子：如何解读Windows安装程序日志。

结论

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

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

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

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

对于经验丰富的 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 安装程序和 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 回显到标准输出而不是记录到文件（高级主题，使用外部 gui 用于 MSI，更多开发人员内容）
• 我想安装 MSI 两次（实例转换或虚拟化 - 认真 :-) ）。
• 如何使用 ActiveSetup 更新每个用户配置文件（有点危险，但很有用）
• MSI 包中的常见错误（更多针对开发人员，也针对系统管理员）
• 如何调试循环自修复（重要课题）

概念主题/最佳实践：

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

Answer 2

只是一些好处：

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

我认为当我在企业环境中部署软件时：通过 MSI 部署软件几乎是令人愉快的。相比之下，我几乎总是发现自己害怕在另一个容器中部署软件。

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

Answer 3

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

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 最佳实践文章。

Answer 4

使用 MSI 还使修补（MSP 文件）和升级更容易。MSI 使用独特的产品和升级代码的概念，这使得整个过程更容易。

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

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