WIX 不会卸载旧版本

Question

经过一些谷歌搜索后，我想出了一个配置，它应该允许我只安装我的包的较新版本（它确实如此），同时替换旧的，已经安装的版本（它没有）

我的wxs文件如下：

<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
    <Product Id="*"
             Name="Gdml File Viewer" Language="1033"
             UpgradeCode="5fb07c15-32a5-4b8a-9794-e4425bfc2eea"
             ...>
        <Package InstallerVersion="200"
                 Compressed="yes"
                 InstallScope="perMachine" Platform="x64" />
        <MajorUpgrade Schedule="afterInstallValidate"
                      DowngradeErrorMessage="A later version of [ProductName] is already installed"
                 AllowSameVersionUpgrades="no"
                 AllowDowngrades="no" />
...

正如预期的那样，它确实允许我安装较新的版本，但未卸载旧版本。它仍然出现在 "Apps & features" 列表中：

(另一个实例版本为2019.14.181.35181)

Answer 1

Logging: To properly debug a failed major upgrade you need to (various ways to create log file - also by policy).
msiexec.exe /i C:\Path\Your.msi /L*v C:\Your.log
Auto-logging could be on: check the TEMP folder for any auto-generated log files there. If not, run again on a virtual to reproduce the upgrade problem with logging enabled.

Failed Major Upgrade: When you see two entries in Add / Remove Programs your major upgrade has failed (generally). You need to fix the configuration of the Upgrade table. See likely causes listed below.

Minimal WiX Markup: The minimal WiX markup for a default upgrade table - with normal parameters (which works fine, see below with screenshot) - is just:
<MajorUpgrade DowngradeErrorMessage="A newer version of [ProductName] is already installed." />
Advanced: It is even possible to combine the above "convenience element" for simple major upgrade configuration with old-style elements for total control of Upgrade table content. .

重大升级：重大升级和升级元素。如何使用它们：

可能的原因：主要升级失败的许多可能原因的简短总结。

Mismatched Upgrade Code: There might be a mismatch in the upgrade codes between the old and the new version of the MSI so the products are not identified as related. This should leave two versions installed afterwards (uninstall of old version never happened).

Missing Upgrade Code: Just adding that it is possible for the upgrade code to be missing from the Product element. This is generally an error, unless you want to do something specifically weird.

Missing MajorUpgrade Element: The whole Major Upgrade element can be missing and no Upgrade element present. The latter is for manual configuration of major upgrades, the former for "auto-magical" implementation of typical major upgrade scenarios. Sort of "best practice".

ProductVersion: There might not have been a bump up of one or more of the first 3 digits in the product version (fourth field ignored).

Product Code: As a side-note you might get a warning that the product is already installed, this means the product code has NOT changed (which it should for a major upgrade).

Dangling Version: It is also possible that your WiX markup is fine, and you have a dangling older version that was never correctly configured, if so uninstall it manually and try again or try on a clean virtual. If you you can end up with several versions of your product installed at once if the major upgrade isn't set up properly.

Installation Context: MSI files can install per-user or per-machine. If you have an installation per-user and then run a per-machine installation it will not detect the previous version. Do you have any hard coded references to ALLUSERS in your package?

SecureCustomProperties: Quickly - while I remember - in secure environments (corporate environments with users running without admin rights) you need to add the ACTION property from the Upgrade table to the list of secure properties (properties allowed to be passed to deferred mode).

Package Code: A very special case I have seen is when the new package has the same package code as the old one (or an existing installed package). This is an extreme design error and must not occur. Always auto-generate the package code, it is the right way to do things. Windows Installer will treat the two packages as identical by definition (as opposed to actual fact - you won't believe the X-Files that can result).

更多详细信息：还有一些需要记住的事情：

主要升级本质上是卸载旧版本并安装新版本，并为操作发生的顺序提供了许多计划选项（先安装新版本，然后卸载旧版本反之亦然）。
如上所述，您还可能在未正确配置的盒子上安装了散乱的旧版本设置，或者发生了一些 X-Files 无意义的事情导致升级失败。发生了。
WiX 不太可能，但 InstallExecuteSequence 中可能缺少标准操作 RemoveExistingProducts。

WiX Learning Curve：建议使用一些示例来帮助加快学习过程。唯一真正有帮助的是什么？ Here are some WiX Quick Start Suggestions。那里有示例链接。

最小 WiX 示例：有这个旧示例：Transparent Aluminum. Essentially a walk-through of how to use Votive 创建一个 WiX-based 安装程序。它包括一个主要的升级元素。我相信这个简单的配置增加了您寻求的降级保护：

<MajorUpgrade DowngradeErrorMessage="A newer version of [ProductName] is already installed." />

查看 Upgrade table 结果：

测试案例：使用透明铝作为测试项目，您可以尝试此过程使升级工作：

将产品代码设置为 * 以便 auto-generate 每个构建的新产品代码 ("<Product Id="*" ...").
编译 MSI 的第一个版本。在 Visual Studio 和 select Open Folder in File Explorer 的解决方案视图中右键单击 WiX 项目。进入 bin 和 Debug 或 Release.
通过在文件名末尾添加 _1 来重命名已编译的 MSI。例如：MySetup_1.msi
现在增加 WiX 源中产品版本字段的前 3 位数字之一：<Product Id="*" ... Version="2.0.0"
编译新的 MSI 并重命名：MySetup_2.msi
从版本 1 开始安装 MSI 文件，然后是第二个。验证主要升级是否成功。

Advanced：这里演示了使用便利元素 [=74= 的组合来配置主要升级的高级方法]"MajorUpgrade" 和较旧的 "Upgrade" 元素（允许您更多 fine-grained 控制由此产生的升级 table ):

这里是一个示例，它仅使用较旧的升级元素会导致更多工作，但会完全控制升级 table：。

链接:

Upgrading a WiX generated package with major version zero

WIX 不会卸载旧版本

WIX does not uninstall older version

windows-installer

wix