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安裝文件但是當我這樣做時，我會讓它們永久。