Jak wdrożyć aktualizację instalatora WiX?

W pracy używamy WiX do budowania pakietów instalacyjnych. Chcemy, aby instalacja produktu X spowodowała odinstalowanie poprzedniej wersji tego produktu na tym komputerze.

Czytałem w kilku miejscach w Internecie o dużym uaktualnieniu, ale nie mogłem go uruchomić. Czy ktoś może podać dokładne kroki, które muszę wykonać, aby dodać funkcję odinstalowania poprzedniej wersji do WiX?

W najnowszych wersjach (z wersji beta 3.5.1315.0) możesz używać elementu MajorUpgrade zamiast własnego.

Na przykład używamy tego kodu do automatycznych aktualizacji. Zapobiega obniżeniu wersji, wyświetla lokalny komunikat o błędzie, a także zapobiega uaktualnianiu już istniejącej identycznej wersji (tj. Uaktualniane są tylko wersje niższe):

<MajorUpgrade
    AllowDowngrades="no" DowngradeErrorMessage="!(loc.NewerVersionInstalled)"
    AllowSameVersionUpgrades="no"
    />

Wreszcie znalazłem rozwiązanie - zamieszczam je tutaj dla innych osób, które mogą mieć ten sam problem (wszyscy 5 z was):

• Zmień identyfikator produktu na *

• W ramach produktu dodaj:

  <Property Id="PREVIOUSVERSIONSINSTALLED" Secure="yes" />
  <Upgrade Id="YOUR_GUID">  
     <UpgradeVersion
        Minimum="1.0.0.0" Maximum="99.0.0.0"
        Property="PREVIOUSVERSIONSINSTALLED"
        IncludeMinimum="yes" IncludeMaximum="no" />
  </Upgrade> 

• W obszarze InstallExecuteSequence dodaj:

  <RemoveExistingProducts Before="InstallInitialize" /> 

Od teraz, kiedy instaluję produkt, usuwałem poprzednie zainstalowane wersje.

Uwaga: zastąp identyfikator aktualizacji własnym identyfikatorem GUID

Oto rodzaj składni, której używam do głównych aktualizacji:

<Product Id="*" UpgradeCode="PUT-GUID-HERE" Version="$(var.ProductVersion)">
 <Upgrade Id="PUT-GUID-HERE">
    <UpgradeVersion OnlyDetect="yes" Minimum="$(var.ProductVersion)" Property="NEWERVERSIONDETECTED" IncludeMinimum="no" />
    <UpgradeVersion OnlyDetect="no" Maximum="$(var.ProductVersion)" Property="OLDERVERSIONBEINGUPGRADED" IncludeMaximum="no" />
</Upgrade>

<InstallExecuteSequence>
    <RemoveExistingProducts After="InstallInitialize" />
</InstallExecuteSequence>

Jak zauważył @Brian Gillespie, istnieją inne miejsca do zaplanowania RemoveExistingProducts w zależności od pożądanych optymalizacji. Uwaga: PUT-GUID-HERE musi być identyczny.

Element aktualizacji w elemencie produktu w połączeniu z odpowiednim zaplanowaniem akcji spowoduje odinstalowanie, którego szukasz. Pamiętaj, aby podać kody aktualizacji wszystkich produktów, które chcesz usunąć.

<Property Id="PREVIOUSVERSIONSINSTALLED" Secure="yes" />
<Upgrade Id="00000000-0000-0000-0000-000000000000">
  <UpgradeVersion Minimum="1.0.0.0" Maximum="1.0.5.0" Property="PREVIOUSVERSIONSINSTALLED" IncludeMinimum="yes" IncludeMaximum="no" />
</Upgrade>

Pamiętaj, że jeśli jesteś ostrożny ze swoimi kompilacjami, możesz zapobiec przypadkowemu zainstalowaniu starszej wersji Twojego produktu na nowszej. Do tego służy pole Maximum. Kiedy budujemy instalatory, ustawiamy UpgradeVersion Maximum do tworzonej wersji, ale IncludeMaximum = „no”, aby zapobiec temu scenariuszowi.

Masz do wyboru harmonogram planowania RemoveExistingProducts. Wolę zaplanować to po InstallFinalize (niż po InstallInitialize, jak zalecili inni):

<InstallExecuteSequence>
  <RemoveExistingProducts After="InstallFinalize"></RemoveExistingProducts>
</InstallExecuteSequence>

Pozostawia to poprzednią wersję produktu zainstalowaną do momentu skopiowania nowych plików i kluczy rejestru. To pozwala mi migrować dane ze starej wersji do nowej (na przykład zmieniłeś przechowywanie preferencji użytkownika z rejestru na plik XML, ale chcesz być uprzejmy i migrować ich ustawienia). Ta migracja jest wykonywana w odroczonej akcji niestandardowej tuż przed InstallFinalize.

Kolejną korzyścią jest wydajność: jeśli istnieją niezmienione pliki, Instalator Windows nie zawraca sobie głowy kopiowaniem ich ponownie, gdy planujesz po InstallFinalize. Jeśli planujesz po InstallInitialize, poprzednia wersja jest najpierw całkowicie usuwana, a następnie instalowana jest nowa wersja. Powoduje to niepotrzebne usuwanie i ponowne kopiowanie plików.

Aby zapoznać się z innymi opcjami planowania, zobacz temat pomocy RemoveExistingProducts w MSDN. W tym tygodniu link to: http://msdn.microsoft.com/en-us/library/aa371197.aspx

Być może lepiej zapytać o to na liście mailingowej użytkowników WiX .

Z WiX najlepiej jest korzystać przy dokładnym zrozumieniu działania Instalatora Windows. Możesz rozważyć uzyskanie „ Przewodnika po Instalatorze Windows ”.

Działanie, które usuwa istniejący produkt, jest działaniem RemoveExistingProducts . Ponieważ konsekwencje tego, co robi, zależą od tego, gdzie jest zaplanowane - mianowicie, czy awaria powoduje ponowną instalację starego produktu i czy niezmienione pliki są ponownie kopiowane - musisz sam to zaplanować.

RemoveExistingProductsprzetwarza <Upgrade>elementy w bieżącej instalacji, dopasowując @Idatrybut doUpgradeCode (określonego w <Product>elemencie) wszystkich zainstalowanych produktów w systemie. UpgradeCodeDefiniuje rodzinę produktów pokrewnych. Wszelkie produkty, które mają ten kod aktualizacji, których wersje mieszczą się w określonym zakresie i w których UpgradeVersion/@OnlyDetectatrybut jest no(lub jest pominięty), zostaną usunięte.

Dokumentacja dla RemoveExistingProducts wspomina o ustawianiu UPGRADINGPRODUCTCODEwłaściwości. Oznacza to, że proces odinstalowywania usuwanego produktu otrzymuje tę właściwość, której wartością jest Product/@Idprodukt, który jest instalowany.

Jeśli oryginalna instalacja nie zawierała UpgradeCode, nie będzie można korzystać z tej funkcji.

Skorzystałem z tej witryny, aby pomóc mi zrozumieć podstawy aktualizacji WiX:

http://wix.tramontana.co.hu/tutorial/upgrades-and-modularization

Następnie utworzyłem przykładowy instalator (zainstalowałem plik testowy), a następnie utworzyłem instalatora uaktualnienia (zainstalowałem 2 przykładowe pliki testowe). To da ci podstawowe zrozumienie działania mechanizmu.

I jak powiedział Mike w książce Apress „The Definitive Guide to Windows Installer”, pomoże ci to zrozumieć, ale nie jest napisane przy użyciu WiX.

Inną stroną, która była bardzo pomocna, była ta:

http://www.wixwiki.com/index.php?title=Main_Page

Przeczytałem dokumentację WiX , pobrałem przykłady, ale wciąż miałem wiele problemów z aktualizacjami. Niewielkie uaktualnienia nie powodują odinstalowania poprzednich produktów, pomimo możliwości ich określenia. Spędziłem ponad jeden dzień na badaniach i odkryłem, że WiX 3.5 wprowadził nowy tag do aktualizacji. Oto użycie:

<MajorUpgrade Schedule="afterInstallInitialize"
        DowngradeErrorMessage="A later version of [ProductName] is already installed. Setup will now exit." 
        AllowDowngrades="no" />

Ale główną przyczyną problemów było to, że dokumentacja mówi o używaniu parametrów „ REINSTALL = ALL REINSTALLMODE = vomus ” w przypadku drobnych i małych aktualizacji, ale nie oznacza to, że parametry te są ZABRONIONE w przypadku dużych aktualizacji - po prostu przestają działać. Dlatego nie powinieneś używać ich z ważnymi aktualizacjami.

Proponuję rzucić okiem na samouczek Alexa Szewczuka. Wyjaśnia „poważną aktualizację” poprzez WiX z dobrym praktycznym przykładem z MSI na WiX, część 8 - Ważna aktualizacja .

Jedną ważną rzeczą, za którą tęskniłem na chwilę od samouczków (skradziony z http://www.tramontana.co.hu/wix/lesson4.php ), co spowodowało błędy „Inna wersja tego produktu jest już zainstalowana”:

* Małe aktualizacje oznaczają niewielkie zmiany w jednym lub kilku plikach, w przypadku których zmiana nie gwarantuje zmiany wersji produktu (major.minor.build). Nie musisz również zmieniać identyfikatora GUID produktu. Pamiętaj, że zawsze musisz zmienić GUID pakietu podczas tworzenia nowego pliku .msi, który pod każdym względem różni się od poprzednich. Instalator śledzi zainstalowane programy i znajduje je, gdy użytkownik chce zmienić lub usunąć instalację za pomocą tych identyfikatorów GUID. Użycie tego samego identyfikatora GUID dla różnych pakietów wprowadzi instalatora w błąd.

Niewielkie aktualizacje oznaczają zmiany, w przypadku których wersja produktu już się zmieni. Zmodyfikuj atrybut Version znacznika Product. Produkt pozostanie taki sam, więc nie trzeba zmieniać identyfikatora GUID produktu, ale oczywiście uzyskać nowy identyfikator GUID pakietu.

Główne aktualizacje oznaczają znaczące zmiany, takie jak przejście z jednej pełnej wersji do drugiej. Zmień wszystko: atrybut wersji, identyfikatory GUID produktów i pakietów.

Korzystam z najnowszej wersji WiX (3.0) i nie mogłem uruchomić powyższej wersji. Ale to zadziałało:

<Product Id="*" UpgradeCode="PUT-GUID-HERE" ... >

<Upgrade Id="PUT-GUID-HERE">
  <UpgradeVersion OnlyDetect="no" Property="PREVIOUSFOUND"
     Minimum="1.0.0.0"  IncludeMinimum="yes"
     Maximum="99.0.0.0" IncludeMaximum="no" />
</Upgrade>

Pamiętaj, że PUT-GUID-HERE powinien być taki sam jak GUID, który zdefiniowałeś we właściwości UpgradeCode produktu.

Poniżej działało dla mnie.

<Product Id="*" Name="XXXInstaller" Language="1033" Version="1.0.0.0" 
    Manufacturer="XXXX" UpgradeCode="YOUR_GUID_HERE">
<Package InstallerVersion="xxx" Compressed="yes"/>
<Upgrade Id="YOUR_GUID_HERE">
    <UpgradeVersion Property="REMOVINGTHEOLDVERSION" Minimum="1.0.0.0" 
        RemoveFeatures="ALL" />
</Upgrade>
<InstallExecuteSequence>
    <RemoveExistingProducts After="InstallInitialize" />
</InstallExecuteSequence>

Upewnij się, że kod aktualizacji w produkcie jest zgodny z identyfikatorem w aktualizacji.

To właśnie działało dla mnie, nawet przy dużej klasie DOWN :

<Wix ...>
  <Product ...>
    <Property Id="REINSTALLMODE" Value="amus" />
    <MajorUpgrade AllowDowngrades="yes" />