MS Installer/Wix中的依賴關係

我目前正在學習WiX和Windows安裝程序的變幻莫測，我已經遇到了一個絆腳石。MS Installer/Wix中的依賴關係

我目前包裝的項目由六個離散塊組成。現在，讓我們稱它們爲A，B，C，D，E和F.

塊A是每個其他項目使用的一組通用庫和實用程序。它不提供任何最終用戶功能。

塊B是需要由塊A提供的功能的另一組通用庫和實用程序。這看起來很奇怪，但是架構超出了我的影響或控制能力。

塊C是第三套公共庫和實用程序，需要由塊A和B提供的功能。這似乎比以前更奇怪，但我仍然無法更改此功能。

大塊d，E和F，都需要由塊提供的功能A，B和C

如果可能的話，我想，以確保只有一個安裝塊A，B ，和C，這些是在D，E和F的安裝中共享的。我已經得到了A，B和C塊將保留穩定的API的保證，以便它們可以升級而不破壞D，E的功能，或F.

我的直接想法是爲A，B和C中的組件創建合併模塊，然後在單獨的安裝程序爲D，E和F提供的功能中引用它們。這會膨脹安裝者，但它會保證th安裝必要的組件。不幸的是，我擔心升級時會導致Windows Installer驗證中出現問題。

我的另一個想法是爲A，B和C製作單個安裝程序，並通過ComponentSearch在D，E和F的安裝程序中進行安裝。

這兩種想法都有道理嗎？如果這兩個想法都沒有意義，那麼你有沒有建議正確的方法來做到這一點？

來源

2009-12-16 dskiles

在每個安裝程序中包含A + B + C，並安裝到常用文件。 Windows Installer將處理引用計數，以便磁盤上只存在一個副本，並保留到最後一個產品被刪除。升級將被罰款，Windows安裝程序是專爲這樣的事情:)

然而，而不是合併模塊，我建議使用Wixlibs

來源

2009-12-16 21:39:28 saschabeaumont

如果我使用熱最初產生威克斯A，B和C的文件是否應該使用片段或模塊模板用於我打算推入wixlib的文件？ – dskiles 2009-12-16 22:32:51

片段（或沒有模板）。產品和模塊增加了你可能不想要的額外東西。 – saschabeaumont 2009-12-17 00:46:18

我已經給予了保證塊A，B，和C將保持穩定的API，使得它們可以在不破壞 d的功能，E，enter code here或F.

阿刺升級 le API可能不夠。如果一個應用程序意外地依賴於沒有記錄的巧合行爲（比如返回列表中的項目順序），或者更糟的是，行爲實際上是一個錯誤，那該怎麼辦？然後共享組件的升級可能會破壞您的應用程序，因爲它未針對升級後的組件進行測試。

我的直接想法是創建合併模塊...我擔心在升級時，會導致Windows 安裝程序驗證中出現問題。

您可能是對的，有合併模塊的可服務性問題。微軟不再自行分發新的合併模塊。創建可升級組件也非常困難，並且仍然遵循Windows Installer Component Rules。

我寧願將「共享」組件分別安裝到每個應用程序的bin文件夾中。我確實爲這些組件創建了wixlibs，以便它們可以在應用程序安裝程序之間共享。在wixlib文件中，我將該組件放在<DirectoryRef Id="SharedComponentFolder>中。此目錄參考未定義，這對lit.exe不是問題。在應用程序安裝程序，然後我別名像這樣的應用程序bin文件夾：

<Directory Id="AppBinFolder" Name="bin"> 
    <Directory Id="SharedComponent1Folder" /> <!-- alias for AppBinFolder --> 
    <Directory Id="SharedComponent2Folder" /> <!-- another alias --> 
</Directory>

其結果是，應用程序有他們依賴於自己的bin文件夾，並保持相互隔離。當然還有一個權衡：

你獲得穩定，因爲您的應用程序始終有違其對所測試的依賴關係的確切版本;沒有DLL Hell問題。
當共享組件更新時，您還有更多工作要做;每個應用程序安裝程序需要更新和重新分發，而不僅僅是共享組件的一個安裝程序。
您丟失磁盤空間（因爲共享組件多次安裝）。

隨着.NET程序集，故事可以變得更加複雜與GAC，strong names，policy file redirects等，但這個帖子已經運行太長:-)

來源

2009-12-16 22:14:48

MS Installer/Wix中的依賴關係

回答

相關問題