WiX：合理的方式；“固定”；新版本安装程序的原始版本卸载问题

我在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 land中完成的。）总之，在创建原始安装程序时，我使用了以下WiX标记来创建COM注册表值：

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

KeyPath

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

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

• 以
  的身份编写一个新的MSI-毕竟，我正在执行升级
• 提供comctl32.ocx和tabctl32.ocx COM库的原始安装程序中的COM注册表项—我猜我需要使用一个CA（或多个CA）来完成此操作，以便在下次升级时不会再次删除它们。我认为有两种方法可以做到这一点：
• 直接创建注册表项，注意确保值与新windows安装的值相匹配（适用于正在执行安装程序的操作系统版本）
• 动态地将要创建的注册表项添加到MSI注册表表中（如果我理解正确，windows installer在卸载方面不会跟踪该注册表项？）

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

我提出的解决方案可以接受吗

替换已删除注册表项的两个选项中哪一个是最好的

如果这两个选项都不可接受，那么有没有人对我如何纠正这种情况提出其他建议，以避免破坏依赖于相关库的其他应用程序

---

这是一本很长的书，但我认为这就是你想要的：

---

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

首先，感谢上面克里斯托弗·派特回答我的问题；尽管如此，这并不是一个真正的答案，因为我正在寻找修复一个“野外”的现有安装程序。不过，在他最后一次关于小升级的评论中，这可能对某些人有用

接下来，感谢艾伦·斯特布纳（Aaron Stebner），他回复了我的电子邮件，要求就同一问题提供指导。他的建议是编写一个没有ID的MSI组件。通过将此类组件编写到MSI中，MSI不会跟踪该组件；本质上，它变成了一个永久的、可卸载的组件。如果完全必要的话，这在这种情况下可能会起作用

然而，在做了一些研究之后，我相信通过删除我上面概述的注册表项来破坏用户系统的风险不大

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

---

如果卸载这些注册表项，可能发生的最坏情况是，依赖这些注册表项的计算机上的其他较旧软件可能最终损坏（例如，该软件从90年代末到2000年代初，使用了非MSI安装程序和/或在全球范围内安装了COM库，这是他们不应该做的，就像我不应该做的一样；））。此时，用户可以使用

regsvr32.exe重新注册COM库，也可以修复/重新安装相关应用程序。在当今这个时代，存在此类应用程序的可能性微乎其微。
我越想这一点，就越觉得无法修复它。我安装了C