WiX：使用新版本安装程序“修复”原始版本卸载问题的合理方法

Question

我在WiX 3.5天内创建了一个基于WiX的安装程序。然后文档比现在更糟糕。更糟糕的是，这是我的第一个安装人员 - 所以我没有做好一切。

一些背景知识：安装程序安装了两个应用程序和一个驱动程序（每个应用程序都是一个由一个或多个组件组成的独立功能）。其中一个应用程序是用VB6编写的供应商专有设备配置应用程序。由于它是VB6应用程序，因此它使用库comctl32.ocx和tabctl32.ocx。

问题的症结在于我没有在Windows Vista（和/或Windows XP）的%windir%\System32文件夹中看到这两个库？我不记得了，自从我第一次写这篇文章以来已经好几年了安装程序）。所以我认为我需要安装这两个库以及所有必需的COM注册表项。 （我最终在我的应用程序文件夹中安装了COM库 - 就像私有程序集一样，但是在HKLM中全局注册它们。）尽管我在创建第一个安装程序时读到了一些内容，但我从来没有遇到过这样的事实：从Windows XP开始，COM组件可以并排安装。 （即便如此，为什么我不使用MSI表Clsid，ProgId等 - 今天授予它们不赞成，但它至少比我做的更正确？但我离题了;做了什么在MSI土地上完成。）无论如何，在创建原始安装程序时，我使用以下WiX标记来创建COM注册表值：

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

我还应该提到的是，当时我还没有遇到任何类型的“组件规则101”类型的文档。因此，此MSI不遵循组件规则。 MSI包含每个COM库的一个组件及其关联的注册表值，其中COM库是其组件的KeyPath。

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

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

• 创建一个新的MSI作为<MajorUpgrade /> - 毕竟，我正在进行升级。
• 提供comctl32.ocx和tabctl32.ocx COM库的原始安装程序中的COM注册表项 - 我猜我需要使用CA（或多个CA）执行此操作，以便他们不要在下次升级时再次删除。我看到实现这两种方法之一：
  1. 直接创建注册表项，注意确保值与全新Windows安装的值相匹配（适用于安装程序正在执行的操作系统版本）
  2. 将要创建的注册表项动态添加到MSI Registry表（如果我理解正确，Windows安装程序在卸载方面不会跟踪它？）

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

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

Answer 1

这是一个很长的阅读，但我认为这是你正在寻找的：

ICE09

引用啤酒广告......我并不总是在SystemFolder中安装文件，但是当我这样做时，我会将它们永久化。

Answer 2

首先，感谢上面的 Christopher Painter 来回答我的问题;但是，从某种意义上说，这并不是一个真正的答案，我正在寻找 - 修复一个“野外”的现有安装程序。尽管如此，在他关于轻微升级的最新评论中，这可能对某些人有用。

接下来，感谢 Aaron Stebner ，他回复了我的电子邮件，要求就此问题提供指导。他的建议是编写一个没有ID的MSI组件。通过将这样的组件编写到MSI中，MSI不跟踪该组件;从本质上讲，它成为一个永久的，无法卸载的组件。如果完全有必要，这可能适用于这种情况。

但是，经过一些研究后，我认为通过删除上面列出的注册表项来破坏用户系统的风险并不大。

我将Windows XP SP3和Windows Vista SP1的新副本加载到虚拟机中。开箱即用，这些版本的Windows都没有在Windows注册表中以任何方式注册有问题的COM组件。这是有道理的，因为从Windows XP开始，已经有了无注册表的COM注册。这也是Windows 8.1的情况 - 再次，这是预期的。

如果卸载这些注册表项，最糟糕的情况是，依赖于此类注册表项的计算机上的某些其他较旧的软件可能最终被破坏（例如，此软件是从90年代末到2000年初的时代，使用了非MSI安装程序和/或全局安装了COM库 - 它们本来就不应该这样做 - 就像我本来不应该做的那样;））。此时，用户可以使用regsvr32.exe重新注册COM库，也可以修复/重新安装相关应用程序。在这个时代，这种应用存在的可能性很小甚至没有。