我可以找到很多关于如何升级微星的信息。例如,关于小升级、小升级、大升级以及它们的用例和限制的信息。但是,我找不到有关合并模块升级行为的信息,例如:
- 似乎 msm 没有任何方法来指定次要、小型或主要升级。那么它的行为方式是什么?它是先卸载旧版本还是只更新更改的文件?
- 有没有办法指定它可以像msi一样从哪个版本升级?
- 我可以为新版本添加/删除/重命名组件吗?
- 如果已安装此 msm 的较新版本并且容器 msi 决定安装,它会被此旧版本的 msm 覆盖吗?
我可以找到很多关于如何升级微星的信息。例如,关于小升级、小升级、大升级以及它们的用例和限制的信息。但是,我找不到有关合并模块升级行为的信息,例如:
合并模块可以参与两种升级场景。第一种是安装程序升级时,它会升级.msm
文件。这发生在像 Visual Studio 服务包这样的情况下,它们提供更新的合并模块供您使用。这可能会产生问题,因为.msm
文件没有文件版本(即使它们有合并模块版本),所以文件版本控制规则不适用。你可能不会问这个案子。
另一种情况是合并模块已合并到将升级的安装程序中。它不再是一个合并模块,而是它的文件和其他记录是消费安装程序的一部分。在这种情况下,.msi
它已合并到其中的 控制升级步骤。两者相互作用,告知您对前三个问题的回答。如果合并模块具有不遵循次要升级规则的更改,则使用安装程序将无法使用次要升级,并且必须诉诸主要升级。相应地,如果您想在使用安装程序中使用(或允许)次要升级,则必须小心您的组件。这可能比在.msi
因为您无法在合并模块中添加新功能。文件版本控制规则将像在所有 Windows Installer 安装中一样适用;因此,您的第四个问题的答案是逐个文件、逐个组件确定的,而不是针对模块的全部内容的组答案。
问题:我相信我需要知道如何按照答案中第二个场景中的描述对合并模块进行版本控制。
情况:
我有许多产品都安装了相同的合并模块。
如果一个产品安装了新版本的合并模块,我不希望不同产品的旧版本覆盖最新的合并模块。
有人可以描述这是否可能,如果可以,如何?