Jak powinienem obsługiwać aktualizacje produktu w instalatorze WiX?

Question

Mam dość duży instalator WiX (250 Mb plus) i staram się wymyślić odpowiednią strategię aktualizacji.

Większość plików instalatora nie ulegnie zmianie i wolelibyśmy nie musieć dystrybuować całego pakietu, gdy zmienił się tylko jeden lub dwa pliki.

Przejrzałem główne i drobne ulepszenia, a moim zdaniem jest to, że ważniejsza aktualizacja nastąpi, jeśli ID produktu ulegnie zmianie, o ile identyfikator aktualizacji pozostanie taki sam i można będzie wprowadzić drobne poprawki uaktualnienia, jeśli obie te wartości pozostaną to samo.

Mam wrażenie, że niewielka aktualizacja za pomocą łatki byłaby najlepszą opcją do obsługi przypadków, w których zmienia się tylko kilka plików, i tylko do odbudowania całego instalatora, gdy zmieni się znaczna liczba plików.

Przetestowałem to przy użyciu "palnika", aby utworzyć plik "wixmst" na podstawie różnic między dwoma plikami "wixpdb", a następnie budując z nich poprawkę. Jednak odkryłem, że mogę tylko łatać od jednej wersji do drugiej (na przykład od 1.0.0 do 1.0.1, a następnie od 1.0.1 do 1.0.2, ale nie od 1.0.0 do 1.0.2). Czy możliwe jest ustalenie minimalnej wersji łaty i obsługa dowolnej wersji powyżej?

Answer 1

Łatka jest bolesna, więc przygotuj się na jej wiele, gdy nauczysz się jej opanować. Oto kolejna strategia, która może ci pomóc. Podziel MSI na 2 MSI (Microsoft nazywa to Micropackages). Mieć podstawowy MSI, który zawiera większą część zawartości, która prawdopodobnie nie ulegnie zmianie, oraz drugi MSI, który jest znacznie mniejszy i zawiera pliki, które powinny być wysokiej przepustowości.

Następnie użyj opcji Nagraj to program ładujący, który obsługuje te połączenia i łączy je razem. Jest to podobne do programu Visual Studio.

Teraz możesz po prostu wysyłać główne aktualizacje drugiego pliku MSI.

Answer 2

Uważam, że możliwe jest poprawianie w scenariuszu opisanym powyżej, o ile nie można odinstalować łat. Przykładowy scenariusz byłby:

1. Instalacja MSI (v1.0)
2. Install MSP (v1.0 - v1.1)
3. Odinstaluj msp (powrót do wersji 1.0), a następnie zainstalować msp (V1 0,0 - v1.2)

więcej informacji na temat odinstalowania łaty można znaleźć w dokumentacji Wix: http://wix.sourceforge.net/manual-wix3/patch_restrictions.htm oraz dokumentacji Windows: http://msdn.microsoft.com/en-us/library/aa372102.aspx.

Należy pamiętać, że aby utworzyć łatki doinstalowania, istnieją pewne ograniczenia i musisz być w WiX 3.0 lub nowszym.

Tak jak wspomniał Christopher, łatanie może być uciążliwe. Zauważyłem, że w wielu przypadkach moi menedżerowie mogą poprosić o możliwość uaktualnień łatek, gdy wszystko, co naprawdę znaczą, oznacza, że ​​użytkownik może dokonać aktualizacji bez ręcznego instalowania, co może być wykonane przez poważną aktualizację.

To powiedziawszy, jeśli masz klientów, którzy wymagają wielu małych aktualizacji, które są często pobierane, łatanie może być warte dodatkowego wysiłku.

Answer 3

Podczas gdy odpowiedź Christophers jest niesamowita, ponieważ sugeruje bootstrapera wix, zniechęciłbym do trasy aktualizacji głównych dla pakietu "high-churn".Problem polega na tym, że po wykonaniu łatki ładującej, która wewnętrznie dokonuje znacznej aktualizacji twoich ulotnych bibliotek w HighChurn.msi od wersji v1.0 do v1.1, bootstrapper nie będzie, według mojej wiedzy, ponownie zainstalować poprzedniego pakiet HighChurn.msi w wersji 1.0.

Istnieje kolejna ścieżka: na pewno możesz stworzyć poprawki, które będą ukierunkowane na wydanie głównej paczki. Biorąc pod uwagę to, co napisałeś, nie jestem do końca pewien, ale jeśli twoja łatka 1.2 może być zastosowana tylko do wersji 1.1, prawdopodobnie zmieniłeś 1.2 tylko przeciwko 1.1, a nie 1.0.

Oto schludny przypomnienie, jak tworzyć łatki: https://www.firegiant.com/wix/tutorial/upgrades-and-modularization/patchwork/

Śledź ten przewodnik, zrobić zastępując łatek ([PatchFamily/@ zastępują], to będziemy robić wszystko, co unieważnia v1.2 v1.1 dostarczonymi, więc są w zasadzie zmuszeni do wprowadzenia poprawki v1.2 v1.0, a nie v1.1) i dodania tej flagi do elementu łatki w celu wybrania wersji głównej, nawet jeśli obecne są wyższe wersje: Patch/@MinorUpdateTargetRTM="yes". Zawsze zmieniaj swoje łatki względem instalatora wydania (HighChurn.msi v1.0), nigdy przeciwko instalatorowi używanemu do łaty (HighChurn.msi v1.1).

Istnieją oczywiście sytuacje, w których może zaistnieć potrzeba zainstalowania aktualizacji dla poprawek: Dobrze zaplanowany schemat pakietu poprawek/usług, na przykład, gdy poprawka 1.1.1 wymaga dodatku Service Pack 1.1 zainstalowanego na wersji 1.0.

Ostatnie słowo na temat łatania waszych danych lotnych (przypuszczam, że tutaj są tu biblioteki z wersjami): Być może warto mieć oko na to, które biblioteki można w zasadzie zamienić w łatce. Następnie możesz tworzyć łaty z bardzo małą ilością danych, nadając zmienionym bibliotekom tylko wyższą wersję. Jeśli zwiększysz wersję na wszystkich twoich bibliotekach, wszystkie biblioteki zostaną załatane, co spowoduje większe poprawki. Może to wymagać nieco bardziej skomplikowanego procesu budowania (Bóg wie, że to zrobiło dla nas).