首页 文章

使用MSM而不是MSI有哪些限制/好处?

提问于
浏览
2

我目前正在构建通过MSI Windows Installer分发的产品 . 该产品由我们的客户使用不同的形式集成在我们自己的MSI中,使用WiX Burn之类的引导程序/链接器或InstallShield等创作工具 .

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

2 回答

  • 2

    在纸上合并模块很好,但在现实世界中,我发现它们笨拙地更新并因此容易出错,因为它们可能在被发现有缺陷之前被合并到许多设置中 . 结果 I do not recommend merge modules at all . 我更喜欢 single MSI ,可以作为 batch process via a bootstrapper or batch file 运行,也可以轻松更新 . 这避免了通常不直观的各种问题 .

    我想补充一点,合并模块适用于 truly shared files 安装在文件系统中适用于 shared fileschange infrequently 的位置 . 这些通常是 OS-runtimes . 这些合并模块通常经过严格测试并且工作正常 . 但是,我经常看到人们使用合并模块来处理最终频繁更改的文件,然后他们最终以特别的方式安装在不同位置的不同位置 . 这种使用是一团糟,浪费了大量的精力 .

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

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

  • 3

    合并模块没有任何问题 . 它们的主要用途(未提及)是共享 . 如果您希望在多个MSI文件中使用相同的共享文件集,则它们需要相同的组件指令集来保留共享规则 . 或者,如果您要将文件提供给客户,以便他们在MSI版本中使用(如Microsoft),则为其提供合并模块 . 这是MS和其他供应商重新分配合并模块的原因之一,这样每个人都可以构建他们的MSI并将它们安装在同一系统上而不会发生文件共享灾难 . 我还看到合并模块用作MSI文件的通用UI . 但主要是它们对于确保正确使用共享文件至关重要 . 我将从经验中告诉您,由于使用合并模块导致的任何感知困难,因错误使用共享文件而导致的灾难要严重得多 . 另请注意,它们是通用的,可以包含在构建MSI文件的所有工具中 .

    我从来没有发现合并模块很难修补,版本或修复 . 主要升级不是问题 . 我见过的唯一潜在问题是构建过程在创建补丁(.msp)构建期间重建合并模块中的所有二进制文件 . 如果只有一个二进制文件需要修复,但你将它们全部编译,它们的版本和内部可能会发生足够的变化,以便修补程序进程(两个MSI文件及其内容之间的增量)会告诉您它们需要包含在补丁中,因为它们已经改变了,但如果这个问题实际上是一个问题就可以避免这个问题 .

相关问题