wix - 使用 MSM 代替 MSI 有哪些限制/好处？

Question

我目前正在构建一个通过 MSI Windows Installer 分发的产品。我们的客户正在使用不同的形式（例如我们在他们自己的 MSI 中）集成该产品，使用 WiX Burn 之类的引导程序/链接器或 InstallShield 之类的创作工具。

考虑到这种情况，我一直想知道使用合并模块 (MSM) 而不是保留 MSI 的限制和/或好处是什么，以及现在推荐的选择一个反对另一个的方法是什么。

Answer 1

纸面上的合并模块很好，但在现实世界中，我发现它们更新起来很笨拙，因此容易出错，因为它们可能会在被发现有缺陷之前被合并到许多设置中。因此，我根本不推荐合并模块。我更喜欢可以通过引导程序或批处理文件作为批处理运行并且也可以轻松更新的单个 MSI 。这避免了通常不直观的各种问题。

我想补充一点，合并模块适用于安装在文件系统中用于共享文件且不经常更改的位置中的真正共享文件。这些通常是OS-runtimes。这些合并模块通常经过大量测试并且工作正常。但是，我经常看到人们使用合并模块来处理最终经常更改的文件，然后他们最终以临时方式以不同的方式安装在不同的位置。这种使用完全是一团糟，而且非常浪费精力。

说了这么多——当我需要高级发布管理时，我确实成功地使用了合并模块，通过合并模块将一组文件重复、不变地包含到几个设置中。即便如此，我在一段时间后遇到了版本问题，有几个文件需要更新，随后，当我将项目留给其他人时使用了错误的合并模块，出现了小错误。由于一个小的合并模块错误修复，我还经历过必须重建所有设置。然后所有设置都必须再次通过 QA。如此紧密的耦合非常令人沮丧。

如果您的要求很简单，并且您不承担共享大量文件的大型多产品发布项目，请使用MSI而不是MSM。更容易理解，通常需要处理的工作更少，原子更新更多，并且由于合并模块更新或设计问题在许多设置中引入相同错误的风险更小。

Answer 2

合并模块没有什么问题。它们的主要用途（尚未提及）是共享。如果您想在多个 MSI 文件中使用相同的共享文件集，它们需要相同的组件 guid 集来保留共享规则。或者，如果您将文件提供给客户端以供他们在其 MSI 构建中使用（如 Microsoft），则为他们提供合并模块。这就是 MS 和其他供应商重新分发合并模块的原因之一，以便每个人都可以构建他们的 MSI 并将它们安装在同一系统上，而不会出现文件共享灾难。我还看到了用作 MSI 文件的通用 UI 的合并模块。但主要是它们对于确保正确使用共享文件至关重要。一世' 我会根据经验告诉你，错误使用共享文件导致的灾难比使用合并模块的任何感知困难要严重得多。另请注意，它们是通用的，可以包含在构建 MSI 文件的所有工具中。

我从未发现难以修补、版本或修复合并模块。重大升级不是问题。我看到的唯一潜在问题是在创建补丁 (.msp) 构建期间重建合并模块中的所有二进制文件的构建过程。如果只有一个二进制文件需要修复，但您将它们全部编译，它们的版本和内部结构可能会发生足够的变化，以至于补丁过程（两个 MSI 文件及其内容之间的差异）会告诉您它们需要包含在补丁中，因为它们'已经改变，但如果它确实是一个问题，则可以避免这个问题。