2016-09-15 69 views
0

次要升級我有一個維克斯安裝該安裝程序是版本我已經成功地進行了補丁來實現以下升級:與維克斯修補

1.0.0 - > 1.0.1

1.0。 0 - > 1.0.2

1.0.1 - > 1.0.2

這工作我已經從1.0.0每次做出新的.msp文件複製到目標版本號。所以根據我的理解,補丁是如何在幕後工作的,如果我最初是從1.0.0到1.0.1的補丁,那麼我創建了一個新的從1.0.0到1.0.2的版本,如果我要運行的話新的補丁,舊的補丁將被卸載,新的補丁將取代它。

如果我的理解是正確的,那麼這意味着修補程序文件的大小會隨着您更改代碼的數量而不斷增加,因此我希望有一個解決方案來解決這個問題,在某些時候我會增加次要版本,然後開始修補過程結束。

比如我想做到這一點:

1.0.0 - > 1.0.12可以用patch1.msp處理。然後我創建一個patch2.msp,它將開始基於版本1.0.12創建補丁。示例升級路徑可能如下所示:

1.0.0 - > patch1.msp - > 1.0.12 - > patch2.msp - > 1.1.0 - > patch3.msp 1.1.0 - > 1.1.x

有什麼辦法可以做到這一點?或者我需要重新安裝.msi文件並繼續從那裏進行修補?

回答

3

首先,安裝替代MSP不會刪除被替代的MSP。被取代的MSP被簡單標記爲取代(不活動)。如果您稍後移除替代的MSP,則先前替代的MSP將重新激活。

爲了刪除MSP,您需要使用舊的過時方法,但我真的不建議這樣做。這不僅難以管理,而且還意味着,例如,如果您修復了之前已刪除的修補程序中的安全錯誤,則在刪除較新的修補修補程序時,安全漏洞未被修補。這是自MSI 3.0以來已經出現的超頻的美化。

對於你的問題,雖然我不推薦它。 MSP最好以基線爲目標。是的,他們可能會變得更大一些,但前提是您要添加內容。如果更新的版本只是更新文件集或其他資源,則針對單個MSI的MSP不應該比基本MSI更大(因爲CAB嵌入MSP並始終應該是MSI +外部CAB)。有關小型更新MSP的更多信息,請參見https://blogs.msdn.microsoft.com/heaths/2007/03/30/small-updates-should-usually-target-a-single-baseline/;關於如何支持使用次要更新MSP支持針對單個基準的目標,請參閱https://blogs.msdn.microsoft.com/heaths/2006/06/14/cumulative-service-packs-with-minorupdatetargetrtm/

雖然這是可能的。在構建每個修補程序時,您需要保存升級MSI,因此,當您創建1.0.1 MSI以便與1.0.0進行有效比較來構建MSP時,那麼當您構建下一個MSP時,需要將1.0.1與1.0進行比較。 2。不過,這些MSP必須是次要更新MSP。這意味着ProductVersion屬性包含在補丁創作轉換中;否則,MSI 1.0.0 + MSP 1.0.1視圖不會更改ProductVersion,因此MSP 1.0.2永遠不會適用。你應該開始看到這很難爲你維護(更不用說強制客戶必須安裝每個以前版本的MSP,如果他們剛剛從你的RTM出發,這對他們來說不是一個好的體驗)。

總之,讓您的客戶容易。只需使用MSP本身的MsiPatchMetadata表中的MinorUpdateTargetRTM屬性定位相同的基準。

1

根據我的經驗,通常的做法是在某個時候創建​​一個主要升級MSI(請參閱WiX mainupgrade元素)。這個帶有新ProductCode且版本高於上一個補丁版本(例如2.0.0)的MSI將升級1.0.0和1.0.12之間的所有版本。然後你開始基於2.0.0產品進行修補。

修補程序中有多個選項可以替換每個整個文件或通過對每個文件進行二進制修補來修補 - 我不確定您使用的是哪一個,但顯然如果您爲一個大文件創建一個小補丁,大於補丁是對該文件的二進制更新。