【问题标题】:How merge module upgrades?合并模块如何升级?
【发布时间】:2009-12-11 06:31:26
【问题描述】:

我可以找到很多关于微星如何升级的信息。例如。有关小升级、小升级、大升级及其用例和限制的信息。但是,我找不到有关合并模块的升级行为的信息,例如:

  1. 好像msm没有 指定小、小或 重大升级。那么它是哪种方式 表现在?是否卸载旧 版本第一或仅更新更改 文件?
  2. 有什么方法可以指定 可以升级哪个版本 像微星?
  3. 我可以添加/删除/重命名吗 新版本的组件?
  4. 如果此 msm 的更新版本是 已经安装和容器 微星决定安装,会吗 用这个旧版本的覆盖 私信?

【问题讨论】:

    标签: windows-installer merge-module


    【解决方案1】:

    合并模块可以参与两种升级方案。第一种是安装程序升级时,它会升级.msm 文件。这发生在像 Visual Studio 服务包这样的情况下,它们提供更新的合并模块供您使用。这可能会产生问题,因为.msm 文件没有文件版本(即使它们有合并模块版本),所以文件版本控制规则不适用。你可能不是在问这个案子。

    另一种情况是合并模块已合并到将要升级的安装程序中。它不再是一个合并模块,而是它的文件和其他记录是消费安装程序的一部分。在这种情况下,它已合并到的.msi 控制升级步骤。两者相互作用,告知您对前三个问题的回答。如果合并模块具有不遵循次要升级规则的更改,则使用安装程序将无法使用次要升级,并且必须诉诸主要升级。相应地,如果您想在使用安装程序中使用(或允许)次要升级,则必须小心您的组件。这可能比.msi 更难,因为您无法在合并模块中添加新功能。文件版本控制规则将像在所有 Windows Installer 安装中一样适用;因此,您的第四个问题的答案是逐个文件、逐个组件确定的,而不是针对模块的全部内容的组答案。

    【讨论】:

    • 很好的答案。这确实是第二种情况。 Windows 安装程序图片对我来说越来越清晰......
    【解决方案2】:

    问题: 我相信我需要知道如何按照答案中的第二种情况对合并模块进行版本控制。

    情况:

    我有许多产品都安装了相同的合并模块。

    如果一个产品安装了新版本的合并模块,我不希望其他产品的旧版本覆盖最新的合并模块。

    有人可以描述这是否可行,如果可以,如何实现?

    【讨论】:

    • 这真的应该是它自己的独立问题(必要时参考这个问题)。如果合并模块及其较新版本的编写良好,则应该可以正常工作。较新的文件版本将覆盖较旧的文件,反之亦然。共享组件代码将正确引用计数,因此即使卸载最新文件的单个用户也不会删除共享文件。简而言之:在升级此合并模块的设计时,请确保遵循组件和文件版本控制规则,理想情况下只更新现有文件。那么一切都应该正常工作。
    • 我很难找到关于这方面的详细文档,所以这是我从实验中确认的:鉴于:合并模块的 2 个版本,称它们为 MMv1.msm 和 MMv2.msm;每个 .msm 包含 1 个文件 MyFile.dll; MMv1.msm 有 v1.0 的 MyFile.dll; MMv2.msm 有 v2.0 的 MyFile.dll; MMv1.msm 由应用程序 A1 的安装程序使用; MMv2.msm 用于应用 A2。那么,当... 1) 安装了 App A1,然后是 A2 时会发生什么? MyFile 在 v2.0 完成; 2)A1,然后A2,安装,然后只是A2被卸载? MyFile 仍为 v2.0。 3)安装了A2,然后A1? MyFile 从 v2.0 开始并保持在 v2.0。
    猜你喜欢
    • 1970-01-01
    • 2020-04-25
    • 2023-03-19
    • 2015-04-21
    • 1970-01-01
    • 2013-03-25
    • 1970-01-01
    • 2021-01-23
    • 1970-01-01
    相关资源
    最近更新 更多