WiX:“修复"的合理方式新版本安装程序的原始版本卸载问题 [英] WiX: Reasonable way to "fix" original version uninstall issue with new version installer

问题描述

我早在 WiX 3.5 天就创建了一个基于 WiX 的安装程序.当时的文档比现在更糟糕.更糟糕的是，这是我的第一个安装程序——所以我没有做对.

I created a WiX-based installer back in the WiX 3.5 days. The documentation then was even worse than it is now. To make matters worse, it was my first installer—so I didn't do everything right.

一些背景:安装程序安装了两个应用程序和一个驱动程序(每个都是由一个或多个组件组成的单独功能).有问题的应用程序之一是用 VB6 编写的供应商专有设备配置应用程序.由于它是一个 VB6 应用程序，因此它使用库 comctl32.ocx 和 tabctl32.ocx.

Some background: the installer installed two applications and a driver (each of these were a separate feature consisting of one or more components). One of the applications in question is a vendor-proprietary device configuration application written in VB6. Since it's a VB6 application, it uses the libraries comctl32.ocx and tabctl32.ocx.

问题的关键是我在 Windows Vista(和/或 Windows XP?我不记得了，它是自从我第一次编写这个安装程序以来已经有好几年了).所以我想我需要安装这两个库以及它们所有必需的 COM 注册表项.(我最终在我的应用程序的文件夹中安装了 COM 库——就像在私有程序集一样，但在 HKLM 中全局注册它们.)尽管我在创建第一个安装程序时阅读了很多内容，但我从未遇到过这样一个事实，从 Windows XP 开始，COM 组件可以并排安装.(即便如此，为什么我不使用 MSI 表 Clsid、ProgId 等.今天，这当然是令人不悦的，但它至少比我所做的更正确?但我离题了；什么是done 在 MSI 域中完成.)无论如何，在创建原始安装程序时，我使用以下 WiX 标记来创建 COM 注册表值:

The crux of the problem is that I didn't see these two libraries in the %windir%\System32 folder on Windows Vista (and/or Windows XP? I don't remember, it's been years since I first wrote this installer). So I thought I needed to install these two libraries along with all of their requisite COM registry entries. (I ended up installing the COM libraries in my application's folder—as you would for a private assembly, but registered them globally in HKLM.) As much as I read about things when creating the first installer, I never once came across the fact that, as of Windows XP, COM components could be installed side-by-side. (And even so, why didn't I use the MSI tables Clsid, ProgId, etc.—which granted, today, is frowned upon, but it would at least have been more correct than what I did? But I digress; what's done is done in MSI land.) Anyway, when creating the original installer, I used the following WiX markup for creating the COM registry values:

<RegistryValue ... Action="write" />

我还应该提到，当时我没有遇到过任何类型的组件规则 101"类文档，因为我这次有.所以，这个MSI不遵循组件规则.MSI 为每个 COM 库及其关联的注册表值包含一个组件，COM 库是其组件的 KeyPath.

I also should mention that at the time, I had not come across any sort of 'Component Rules 101' kind of documentation as I have this time around. So, this MSI does not follow the component rules. The MSI contained one component for each COM library and its associated registry values with the COM library being the KeyPath of its component.

问题是，如果在我的原始 MSI 运行和安装我的产品的第一个版本之前这些注册表项/值就存在，卸载是否会导致这些项/值从系统中删除?(我假设这些键/值是在 Windows 安装过程中创建的——那么它们是否已经被引用计数了?)我不想破坏依赖于这些库的用户系统上的其他应用程序.

The question is, if the registry keys/values existed prior to my original MSI running and installing the first version of my product, will uninstallation cause these keys/values to be removed from the system? (I assume these keys/values were created during Windows setup—so are they already reference counted?) I don't want to possibly break other applications on a users' system that relies on those libraries.

如果上面的答案是肯定的，那么我目前纠正这种情况的计划是:

If the answer to the above is yes, then my current plan to rectify the situation is:

• 创建一个新的 MSI 作为 —毕竟，我正在执行升级.
• 为 comctl32.ocx 和 tabctl32.ocx COM 库提供原始安装程序中的 COM 注册表项—我猜我需要用一个 CA(或多个 CA)来做到这一点，这样他们就不会'在下次升级时再次删除.我看到了实现此目的的两种方法之一:

• Author a new MSI as a <MajorUpgrade />—afterall, I am performing an upgrade.
• Provide the COM registry entries that were in the original installer for the comctl32.ocx and tabctl32.ocx COM libraries—I'm guessing that I would need to do this with a CA (or multiple CA's) so that they don't get removed again on the next upgrade. I see one of two ways of accomplishing this:

1. 直接创建注册表项，注意确保这些值与全新 Windows 安装的值匹配(适用于执行安装程序的操作系统版本)
2. 将要创建的注册表项动态添加到 MSI 注册表(如果我理解正确，Windows 安装程序在卸载方面不会跟踪?)

如果以前存在的被 MSI 覆盖的注册表项在卸载时被删除，则:

If previously existing registry keys overwritten by MSI are removed on uninstallation, then:

1. 我提出的解决方案是否可以接受?
2. 替换已删除注册表项的两个选项中哪个最好?
3. 如果这两个选项都不可接受，有没有人对我如何纠正这种情况有任何其他建议，以免破坏(可能)依赖相关库的其他应用程序?

推荐答案

首先感谢上面的Christopher Painter 对我的问题的回答；但是，从我正在寻找的意义上来说，这并不是真正的答案——修复野外"的现有安装程序.不过，在他最后一次关于小升级的评论中，这可能对某些人有用.

First, thanks to Christopher Painter above for responding to my question; though, it's not really an answer in the sense that I'm looking for—fixing an existing installer that's "out in the wild". Though, in his last comment about a minor upgrade, that might work for some people.

接下来，感谢 Aaron Stebner，他回复了我的电子邮件，请求就同一问题提供指导.他的建议是编写一个没有 ID 的 MSI 组件.通过将此类组件创作到 MSI，该组件不会被 MSI 跟踪；本质上，它变成了一个永久的、可卸载的组件.如果完全有必要，这在这种情况下可能会奏效.

Next, thanks to Aaron Stebner who responded to my e-mail requesting guidance on this same issue. His advice is to author a MSI component which has no ID. By authoring such a component into a MSI, the component is not tracked by MSI; essentially, it becomes a permanent, uninstallable component. This might work in this situation, if it were completely necessary.

但是，经过一些研究，我认为删除我上面概述的注册表项不会损坏用户系统.

However, after doing some research, I believe that there isn't much risk to damaging a user's system by removing the registry entries I outlined above.

我将 Windows XP SP3 和 Windows Vista SP1 的新副本加载到虚拟机中.开箱即用，这两个版本的 Windows 都没有在 Windows 注册表中以任何方式注册有问题的 COM 组件.这是有道理的，因为从 Windows XP 开始，就有了免注册的 COM 注册.Windows 8.1 的情况仍然如此——这在意料之中.

I loaded a fresh copy of Windows XP SP3 and Windows Vista SP1 into a virtual machine. Out of the box, neither of these versions of Windows have the COM components in question registered in anyway in the Windows registry. This makes sense, since from Windows XP onward, there has been registry-free COM registration. This also continues to be the case for Windows 8.1—again, this was expected.

如果这些注册表项被卸载，最糟糕的情况是机器上依赖这些注册表项的其他一些较旧的软件最终可能会被破坏(例如，该软件是从 90 年代末到 2000 年代初的时代和使用非 MSI 安装程序和/或全局安装 COM 库——他们一开始就不应该这样做——就像我一开始就不应该那样做 ;) ).此时，用户可以使用 regsvr32.exe 重新注册 COM 库或修复/重新安装有问题的应用程序.在当今时代，此类应用程序存在的可能性微乎其微.

The worst that could happen if these registry keys are uninstalled is that some other older piece of software on a machine that relied on such registry entries could end up broken (e.g. this software is from the late-90's to early 2000's era and used a non-MSI installer and/or installed the COM libraries globally—which they shouldn't have done in the first place—just like I shouldn't have done in the first place ;) ). At that point, the user can either re-register the COM libraries using regsvr32.exe or repair/reinstall the application in question. The likelihood of such applications existing are slim to none in this day and age.

这篇关于WiX:“修复"的合理方式新版本安装程序的原始版本卸载问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！