4

我被要求将版本 1.0.0.0 升级到 1.0.0.1。默认情况下，当我使用虚拟安装程序进行测试时，如果我们更改产品代码，1.0.0.0 和 1.0.0.1 将并排安装。

但如果我们执行 1.0.1.0 版（同时更改产品代码），它会进行升级。这是我的升级部分：

   <Upgrade Id="{354E9DAE-EB70-4BCC-BD93-AC20ACE3F370}">
     <UpgradeVersion
      Maximum="$(var.ver)"
      Property="DOMAJORUPGRADE"
      MigrateFeatures="yes"
      IncludeMinimum="yes"/>
   </Upgrade>

问题：有什么方法可以将 1.0.0.0 升级到 1.0.0.1？

实际上，我得到了这样的场景：

  1. 在 1.0.0.0 之上安装 1.0.0.1 时，需要升级 1.0.0.0。
  2. 在 1.0.0.1 之上安装 1.0.0.0 时，1.0.0.0 需要失败。
  3. 在具有不同产品代码的 1.0.0.1 之上安装 1.0.0.1 时（仅在开发版本中可能），现有的 1.0.0.1 需要卸载。
4

2 回答 2

11

查看帮助主题MajorUpgrade Element：

下面是关于 AllowSameVersionUpgrades 属性的说明：

当设置为 no（默认值）时，MSI 允许安装具有相同版本和升级代码（但产品代码不同）的产品并将其视为两个产品。当设置为 yes 时，WiX 设置 msidbUpgradeAttributesVersionMaxInclusive 属性，该属性告诉 MSI 将具有相同版本的产品视为主要升级。

当两个产品版本仅在第四个版本字段中不同时，这很有用。MSI 在比较产品版本时会特别忽略该字段，因此仅在第四个版本字段不同的两个产品是相同的产品，需要将此属性设置为 yes 才能检测到。

请注意，由于 MSI 忽略第四个产品版本字段，因此将此属性设置为 yes 也允许在前三个产品版本字段相同时进行降级。例如，产品版本 1.0.0.1 将“升级” 1.0.0.2998，因为它们被视为相同的版本 (1.0.0)。这可能会重新引入严重的错误，因此最安全的选择是更改前三个版本字段并省略此属性以获取默认值 no。

当 AllowDowngrades 也为“yes”时，该属性不能为“yes”——AllowDowngrades 已经允许两个具有相同版本号的产品相互升级。

蒂姆的答案是 95% 正确。我真的不建议只更改第 4 个版本。也就是说，有一种方法可以减轻上面提到的“意外降级”错误。编写不检测相同版本的 MajorUpgrade 规则。然后编写一个自定义操作，对第四个字段中更大的产品进行额外检查并共享您的 UpgradeCode。将此检测到的 ProductCode 设置或附加到 ActionProperty。在 FindRelatedProducts 和 RemoveExistingProducts 之间安排此自定义操作，您将获得 Windows Installer 从未设计过的所需行为。

于 2013-05-20T11:07:52.200 回答
5

不，因为 MSI 会忽略版本号的修订部分。MSI 认为版本 1.0.0.0 和 1.0.0.1 完全相同，因为它只查看版本的主要、次要和构建位，即两者相同的 1.0.0。

ProductVersion 属性

于 2013-05-20T08:55:57.050 回答