Frage

Bei der Arbeit verwenden wir WiX für Pakete der Gebäudeinstallation. Wir wollen, dass die Installation von Produkt X in Deinstallation der vorherigen Version dieses Produkts auf dieser Maschine führen würde.

Ich habe im Internet über ein großes Upgrade auf mehreren Stellen gelesen, aber konnte es nicht bekommen zu arbeiten. Die genauen Schritte jemand bitte angeben, die ich ergreifen müssen, um Deinstallation Vorversion Funktion WiX?

hinzufügen
War es hilfreich?

Lösung

In den neuesten Versionen (von der 3.5.1315.0 Beta) können Sie verwenden, um die MajorUpgrade Element stattdessen Ihre eigenen zu verwenden.

Zum Beispiel verwenden wir diesen Code automatisches Upgrades zu tun. Es verhindert, dass Herabstufungen, eine lokalisierte Fehlermeldung zu geben, und auch eine bereits vorhandene identische Version (das heißt nur niedrigere Versionen aktualisiert wird) verhindert ein Upgrade:

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

Andere Tipps

Schließlich fand ich eine Lösung - Ich bin hier für andere Menschen zu veröffentlichen, die das gleiche Problem haben könnten (alle 5 von Ihnen):

  • Ändern Sie die Produkt-ID *
  • Unter Produkt Folgendes hinzu:

    <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> 
    
  • Unter InstallExecuteSequence hinzufügen:

    <RemoveExistingProducts Before="InstallInitialize" /> 
    

Von nun an, wenn ich installieren Sie das Produkt, um es entfernt vorherige installierten Versionen.

Hinweis: ersetzen Upgrade-ID mit Ihrem eigenen GUID

Das folgende ist die Art von Syntax I für größeren Upgrades verwenden:

<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>

Wie @ Brian Gillespie bemerkt gibt es andere Orte, die RemoveExistingProducts planen auf gewünschte Optimierungen abhängig. Beachten Sie die PUT-GUID-HERE müssen identisch sein.

Das Upgrade-Element innerhalb des Elements Produkt mit der richtigen Planung der Aktion kombiniert werden um die Deinstallation sind Sie nach zuführen. Achten Sie darauf, die Upgrade-Codes aller Produkte aufzulisten, die Sie entfernen möchten.

<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>

Beachten Sie, dass, wenn Sie vorsichtig sind mit Ihrem baut, können Sie verhindern, dass Menschen aus Versehen auf einem eine ältere Version des Produkts über einen neuen installieren. Das ist, was das Maximum Feld ist für. Wenn wir Installateure bauen, setzen wir UpgradeVersion Maximum auf die Version gebaut, aber IncludeMaximum = „no“ um dieses Szenario zu verhindern.

Sie haben die Wahl in Bezug auf die Planung von RemoveExistingProducts. Ich ziehe die Planung es nach InstallFinalize (statt nach InstallInitialize wie andere empfohlen):

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

Damit bleibt die vorherige Version des installierten Produkts erst nach den neuen Dateien und Registry-Schlüssel kopiert werden. Auf diese Weise können Sie mir Migration von Daten von der alten Version auf die neuen (zum Beispiel haben Sie geschaltet Speicherung von Benutzereinstellungen aus der Registrierung in eine XML-Datei, aber Sie mögen, höflich sein und migrieren ihre Einstellungen). Diese Migration wird in einer verzögerten Aktion erfolgt kurz vor InstallFinalize.

Ein weiterer Vorteil ist die Effizienz: Wenn es unverändert Dateien, Windows Installer nicht stört sie wieder zu kopieren, wenn Sie nach InstallFinalize planen. Wenn Sie nach InstallInitialize planen, wird die vorherige Version zuerst vollständig entfernt, und dann wird die neue Version installiert. Dies führt zu unnötigem Lösch- und Umkopieren der Dateien.

Für andere Planungsoptionen finden Sie in das RemoveExistingProducts Hilfethema in MSDN. In dieser Woche ist der Link: http://msdn.microsoft.com/en- us / library / aa371197.aspx

Sie besser werden könnten fragen, dies auf der WiX-Benutzer-Mailingliste .

WiX werden am besten mit einem festen Verständnis verwendet, was Windows Installer tut. Man könnte erwägen, " The Definitive Guide to Windows Installer ".

Die Aktion, die ein bestehendes Produkt entfernt ist die RemoveExistingProducts Aktion . Denn die Folgen dessen, was es tut, hängt davon ab, wo es geplant ist - nämlich, ob ein Fehler das alte Produkt verursacht neu installiert werden, und ob geänderte Dateien kopiert werden wieder -. Sie haben es zu planen, sich

RemoveExistingProducts Prozesse <Upgrade> Elemente in der aktuellen Installation, die @Id Attribut dem UpgradeCode (spezifiziert in dem <Product> Element) aller installierten Produkten auf dem System übereinstimmt. Die UpgradeCode definiert eine Familie von verwandten Produkten. Alle Produkte, die dieses Upgrade haben, deren Versionen fallen in den Bereich angegeben ist, und wo das UpgradeVersion/@OnlyDetect Attribut no (oder weggelassen), werden entfernt.

Die Dokumentation für RemoveExistingProducts erwähnt die UPGRADINGPRODUCTCODE Eigenschaft festlegen. Es bedeutet, dass die Deinstallation für das Produkt entfernt werden erhält diese Eigenschaft, dessen Wert der Product/@Id für das Produkt installiert wird.

Wenn Sie Ihre ursprüngliche Installation nicht einen UpgradeCode enthalten, werden Sie nicht in der Lage sein, diese Funktion zu nutzen.

verwendet, habe ich diese Seite mir zu helfen, die Grundlagen über WiX zu verstehen Upgrade:

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

Danach habe ich eine Probe Installer (eine Testdatei installiert ist), erstellt dann das Upgrade-Installationsprogramm (2 Probe-Testdateien installiert ist). Dies wird Ihnen ein grundlegendes Verständnis davon, wie der Mechanismus funktioniert.

Und wie Mike sagte in dem Buch von Apress, "The Definitive Guide to Windows Installer", es wird Ihnen helfen, zu verstehen, aber es ist nicht mit WiX geschrieben.

Eine andere Website, die sehr hilfreich war, war diese:

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

Ich lese die WiX Dokumentation, Beispiele heruntergeladen, aber ich hatte immer noch viele Probleme mit Upgrades. Minor Upgrades nicht ausführen Deinstallation der bisherigen Produkte trotz der Möglichkeit, diese Deinstallation angeben. Ich verbrachte mehr, dass einen Tag für Untersuchungen und fand heraus, dass WiX 3.5 einen neuen Tag für Upgrades intoduced. Hier ist die Nutzung:

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

Aber der Hauptgrund der Probleme war, dass Dokumentation sagt die verwenden „ STALL = ALL REIN = vomus “ Parameter für kleineren und kleinen Upgrades, aber es funktioniert nicht sagen, dass diese Parameter sind VERBOTEN für größeren Upgrades - sie einfach aufhören zu arbeiten. So sollten Sie sie nicht mit großen Upgrades verwendet werden.

Ich würde vorschlagen, einen Blick auf Alex Shevchuk Tutorial haben. Er erklärt: „Major Upgrade“ durch WiX mit einem guten praktischen Beispiel unter Von MSI zu WiX, Teil 8 -. Major Upgrade

Eine wichtige Sache, die ich von den Tutorials für eine Weile verpasst (gestohlen von http://www.tramontana.co .net / wix / lesson4.php ), die in den Folge-Fehler "Eine andere Version dieses Produkts ist bereits installiert":

* Kleines Updates bedeutet kleine Änderungen an einem oder ein paar Dateien, in denen die Änderung garantiert nicht, die Produktversion zu wechseln (major.minor.build). Sie müssen nicht den Produkt-GUID ändern, auch nicht. Beachten Sie, dass Sie immer den Paket-GUID ändern, wenn Sie eine neue .msi-Datei erstellen, die von den vorherigen in jeder Hinsicht anders ist. Der Installer verfolgt Ihre installierten Programme und findet sie, wenn der Benutzer die Installation mit dieser GUIDs ändern oder zu entfernen. Unter Verwendung der gleichen GUID für verschiedene Pakete den Installer verwirren.

Minor Upgrades Änderungen bezeichnen, wo die Produktversion bereits ändern. Ändern Sie die Version Attribut des Produkt-Tag. Das Produkt wird das gleiche bleiben, so dass Sie den Produkt-GUID nicht, aber natürlich ändern müssen, eine neue Paket-GUID erhalten.

Wichtiger Upgrades bezeichnet signifikante Änderungen wie von einer Vollversion zum anderem. Ändern Sie alles:. Version Attribut, Produkt und Verpackung GUIDs

Ich verwende die neueste Version von WiX (3.0) und nicht die obigen Arbeits bekommen kann. Aber das hat funktioniert:

<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>

Beachten Sie, dass PUT-GUID-HERE sollte die gleiche wie die GUID, die Sie in der Upgradecode-Eigenschaft des Produkts festgelegt haben.

arbeitete Below für mich.

<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>

Bitte stellen Sie sicher, dass der Upgradecode in Produkt wird Id bei dem Upgrade entsprechen.

Das ist was für mich gearbeitet, auch bei großen AB Klasse:

<Wix ...>
  <Product ...>
    <Property Id="REINSTALLMODE" Value="amus" />
    <MajorUpgrade AllowDowngrades="yes" />
Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top