使用 MSM 代替 MSI 有哪些限制/好处?

San*_*ero 4 windows-installer wix burn merge-module

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

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

Ste*_*mul 5

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

我想补充一点,合并模块正常工作真正共享的文件安装在都是为了在文件系统中的位置共享文件变化很少。这些通常是操作系统运行时。这些合并模块通常经过大量测试并且可以正常工作。但是,我经常看到人们将合并模块用于最终频繁更改的文件,然后他们最终以特殊方式安装在不同位置的不同风格。这种使用完全是一团糟,并且浪费了大量精力。

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

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