我目前正在构建通过MSI Windows Installer分发的产品。该产品由我们的客户使用不同的形式集成在我们自己的MSI中，使用WiX Burn等引导程序/链接器或InstallShield等创作工具。
考虑到这种情况，我一直想知道使用合并模块（MSM）而不是保留MSI的限制和/或好处，以及现在推荐的关于选择其中一种方法的方法。
答案 0 :(得分：3)
合并模块没有任何问题。它们的主要用途（未提及）是共享。如果您希望在多个MSI文件中使用相同的共享文件集，则它们需要相同的组件指令集来保留共享规则。或者，如果您要将文件提供给客户端以供其在MSI版本中使用（如Microsoft），则为其提供合并模块。这是MS和其他供应商重新分配合并模块的原因之一，这样每个人都可以构建他们的MSI并将它们安装在同一系统上而不会发生文件共享灾难。我还看到合并模块用作MSI文件的通用UI。但主要是它们对于确保正确使用共享文件至关重要。我将从经验中告诉您，由于使用合并模块导致的任何感知困难，因错误使用共享文件而导致的灾难要严重得多。另请注意，它们是通用的，可以包含在构建MSI文件的所有工具中。
我从未发现合并模块难以修补，版本或修复。主要升级不是问题。我见过的唯一潜在问题是构建过程在创建补丁（.msp）构建期间重建合并模块中的所有二进制文件。如果只有一个二进制文件需要修复，但你将它们全部编译，它们的版本和内部可能会发生足够的变化，以便修补程序进程（两个MSI文件及其内容之间的增量）会告诉您它们需要包含在补丁中，因为它们已经改变了，但如果这个问题实际上是一个问题就可以避免这个问题。
答案 1 :(得分：2)
在纸上合并模块很好，但在现实世界中，我发现它们笨拙地更新并因此容易出错，因为它们可能在被发现有缺陷之前被合并到许多设置中。因此我不建议合并模块。我更喜欢单一MSI ，可以通过引导程序或批处理文件作为批处理进程运行，也可以轻松更新。这避免了通常不直观的各种问题。
我想补充一点，合并模块适用于安装在文件系统中用于共享文件的位置的真正共享文件，并且不经常更改即可。这些通常是 OS-runtimes 。这些合并模块通常经过严格测试并且工作正常。但是，我经常看到人们使用合并模块来处理最终频繁更改的文件，然后他们最终以特殊的方式安装在不同位置的不同位置。这种使用是一种混乱和极大的浪费。
说了这么多 - 当我需要通过合并模块将重复的，不变的一组文件包含到多个设置中时，我确实成功地使用了合并模块。即便如此，我在一段时间后遇到一个版本问题，需要更新几个文件，并且当我将项目留给其他人时，使用了错误的合并模块的后续轻微错误。由于一个小的合并模块错误修复，我还经历了重建所有设置。然后所有设置都必须再次通过QA。这种紧密耦合非常令人沮丧。
如果您的要求很简单并且您没有参与共享大量文件的大型多产品发布项目，请使用 MSI 而不是 MSM 。由于合并模块更新或设计问题，更容易理解，通常需要处理的工作量更少，更多的原子更新以及在许多设置中引入相同错误的风险更小。