WIX 不会卸载旧版本 [英] WIX does not uninstall older version

查看：37
本文介绍了WIX 不会卸载旧版本的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！

问题描述

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

我的wxs文件如下:

<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi"><产品 ID="*"名称="Gdml 文件查看器" 语言="1033"UpgradeCode="5fb07c15-32a5-4b8a-9794-e4425bfc2eea"...><Package InstallerVersion="200"压缩=是"InstallScope="perMachine" Platform="x64"/><MajorUpgrade Schedule="afterInstallValidate"DowngradeErrorMessage="已经安装了更高版本的 [ProductName]"AllowSameVersionUpgrades="no"AllowDowngrades="no"/>...

正如预期的那样，它确实允许我安装较新的版本，但不会卸载较旧的版本.它仍然显示在应用和功能"列表中:

(另一个实例的版本为 2019.14.181.35181)

解决方案

日志记录:要正确调试失败的主要升级，您需要

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

  1. 将产品代码设置为 * 以便为每个构建自动生成新的 ProductCode().
  2. 编译 MSI 的第一个版本.在 Visual Studio 的解决方案视图中右键单击 WiX 项目，然后选择 在文件资源管理器中打开文件夹.进入bin和Debug或Release.
  3. 通过在文件名末尾添加 _1 来重命名已编译的 MSI.例如:MySetup_1.msi
  4. 现在增加 WiX 源中产品版本字段的前 3 位数字之一:
  5. 编译一个新的 MSI 并将其重命名为:MySetup_2.msi
  6. 从版本 1 开始安装 MSI 文件，然后是第二个.验证主要升级是否成功.

高级:这是一个使用便利元素MajorUpgrade"的组合来配置主要升级的高级方法的演示code> 和较旧的 Upgrade" 元素(允许您对生成的升级表进行更细粒度的控制):

<块引用>

向 MSI UpgradeTable 添加条目以删除相关产品

这里是一个仅使用较旧的 Upgrade 元素导致更多工作但完全控制升级表的示例:主要升级- 旧的手动方式".

链接:

After some googling I came up with a configuration that should allow me to install only newer versions of my package (which it does) while replacing the older, already installed version(s) (which it doesn't)

My wxs file is as follows:

<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" />
...

As expected it does allow me to install newer versions, but the older version is not uninstalled. It still shows up in the "Apps & features" list:

(The other instance has version 2019.14.181.35181)

解决方案

Logging: To properly debug a failed major upgrade you need to create a proper log file (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. Samples here.

On Major Upgrades: MajorUpgrade and Upgrade elements. How to use them:

Likely Causes: A short summary of some of many possible causes for failed major upgrades.

  • 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 auto-generate the product GUID 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).

Further Details: Some further things to remember:

  • A major upgrade is essentially an uninstall of the older version and an installation of the new version with a number of scheduling options for the order in which actions take place (install new first, then uninstall old or vice versa).

  • As stated above you could also have a straggling older version of a setup on the box that wasn't properly configured or some X-Files nonsense happened that causes it to fail upgrade. Happens.

  • Unlikely with WiX, but it is possible for the standard action RemoveExistingProducts to be missing from the InstallExecuteSequence.

WiX Learning Curve: Suggest using some samples to help speed up the learning process. The only thing that really helps? Here are some WiX Quick Start Suggestions. There are sample links in there.

Minimal WiX Sample: There is this old sample: Transparent Aluminum. Essentially a walk-through of how to use Votive to create a WiX-based installer. It includes a major upgrade element. I believe this simple configuration adds the protection against downgrade that you seek:

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

See the Upgrade table that results:

Test Case: Using the Transparent Aluminum as test project, you can try this procedure to make the upgrade work:

  1. Set the product code to * in order to auto-generate a new ProductCode for every build ("<Product Id="*" ...").
  2. Compile the first version of your MSI. Right click WiX project in solution view in Visual Studio and select Open Folder in File Explorer. Into bin and Debug or Release.
  3. Rename the compiled MSI by adding _1 to the end of the file name. For example: MySetup_1.msi
  4. Now bump up one of the first 3 digits of the product version field in the WiX source: <Product Id="*" ... Version="2.0.0"
  5. Compile a new MSI and rename it: MySetup_2.msi
  6. Install the MSI files starting with version 1 and then the second one. Verify that major upgrade succeeded.

Advanced: Here is a demo of an advanced way to configure major upgrades using a combination of the convenience element "MajorUpgrade" and the older "Upgrade" elements (that allow you more fine-grained control of the resulting Upgrade table):

Adding entries to MSI UpgradeTable to remove related products

And here is a sample of using only the older Upgrade elements resulting in more work, but total control of the Upgrade table: Major Upgrade - "The Old, Manual Way".

Links:

这篇关于WIX 不会卸载旧版本的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！

查看全文
相关文章
其他开发最新文章
热门教程
热门工具
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆