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安装（适当OS的版本上安装程序正在执行）
  2. 动态将要创建的注册表项添加到MSI注册表中（如果我理解正确，则不会在卸载方面跟踪Windows安装程序？）

如果MSI覆盖先前存在的注册表项上卸载删除，那么：

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

Answer 1

首先，感谢克里斯托弗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库或修复/重新安装相关应用程序。这种应用程序存在的可能性在今天这个时代很少。

Answer 2

这是一个漫长读，但我认为这是你在找什么：

ICE09

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