我被要求将版本 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.0.0.0 之上安装 1.0.0.1 时,需要升级 1.0.0.0。
- 在 1.0.0.1 之上安装 1.0.0.0 时,1.0.0.0 需要失败。
- 当使用不同的产品代码在 1.0.0.1 之上安装 1.0.0.1 时(仅可能在开发版本中),需要卸载现有的 1.0.0.1。
查看帮助主题主要升级元素:
以下是关于AllowSameVersionUpgrades 属性的说明:
当设置为 no(默认)时,安装具有相同功能的产品
允许版本和升级代码(但不同的产品代码)
MSI将其视为两种产品。当设置为 yes 时,WiX 设置
msidbUpgradeAttributesVersionMaxInclusive 属性,告诉 MSI
将具有相同版本的产品视为主要升级。
当两个产品版本仅在第四个版本不同时,这非常有用
版本字段。 MSI 在比较时特别忽略该字段
产品版本,因此两种产品仅在第四个方面有所不同
version 字段是相同的产品,需要将此属性设置为 yes
被检测到。
请注意,由于 MSI 忽略了第四个产品版本字段,
将此属性设置为 yes 还允许在第一次时降级
三个产品版本字段相同。例如,产品
版本 1.0.0.1 将“升级”1.0.0.2998,因为它们被视为
相同版本(1.0.0)。这可能会重新引入严重的错误,因此
最安全的选择是更改前三个版本字段并省略
此属性获取默认值 no。
当AllowDowngrades 也为“yes”时,此属性不能为“yes” --
AllowDowngrades 已允许两个具有相同版本的产品
号可以互相升级。
蒂姆的回答有 95% 正确。我真的不建议只更改第四个版本。也就是说,有一种方法可以减轻上面提到的“意外降级”错误。编写一条不检测相同版本的 MajorUpgrade 规则。然后编写一个自定义操作,对第四个字段中更大的产品进行额外检查并共享您的 UpgradeCode。将检测到的 ProductCode 设置或附加到 ActionProperty。在FindRelatedProducts 和RemoveExistingProducts 之间安排此自定义操作,您将获得Windows Installer 从未设计过的所需行为。
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)