Bei der Arbeit verwenden wir WiX zum Erstellen von Installationspaketen. Wir möchten, dass die Installation von Produkt X zur Deinstallation der vorherigen Version dieses Produkts auf diesem Computer führt.
Ich habe an mehreren Stellen im Internet über ein größeres Upgrade gelesen, konnte es aber nicht zum Laufen bringen. Kann jemand bitte die genauen Schritte angeben, die ich ausführen muss, um WiX die Funktion zur Deinstallation früherer Versionen hinzuzufügen?
Antworten:
In den neuesten Versionen (ab der Beta-Version 3.5.1315.0) können Sie das MajorUpgrade-Element anstelle Ihres eigenen verwenden.
Zum Beispiel verwenden wir diesen Code, um automatische Upgrades durchzuführen. Es verhindert Downgrades, gibt eine lokalisierte Fehlermeldung aus und verhindert auch das Upgrade einer bereits vorhandenen identischen Version (dh nur niedrigere Versionen werden aktualisiert):
<MajorUpgrade
AllowDowngrades="no" DowngradeErrorMessage="!(loc.NewerVersionInstalled)"
AllowSameVersionUpgrades="no"
/><MajorUpgrade>“ Element muss gestellt werden , nachdem <Package> . Andernfalls wird candleder folgende Fehler ausgegeben: "Fehler CNDL0107: Die Schemaüberprüfung ist mit dem folgenden Fehler in Zeile 1, Spalte 473 fehlgeschlagen: Das Element 'Produkt' im Namespace ' schemas.microsoft.com/wix/2006/wi ' hat ein ungültiges untergeordnetes Element. ' MajorUpgrade 'im Namespace' schemas.microsoft.com/wix/2006/wi '. Liste der möglichen erwarteten Elemente:' Package '. "
AllowDowngradesoder AllowSameVersionUpgrades. Sie sind standardmäßig bereits nein.
Endlich habe ich eine Lösung gefunden - ich poste sie hier für andere Leute, die möglicherweise das gleiche Problem haben (alle 5 von Ihnen):
Fügen Sie 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> Fügen Sie unter InstallExecuteSequence Folgendes hinzu:
<RemoveExistingProducts Before="InstallInitialize" /> Von nun an wurden bei jeder Installation des Produkts frühere installierte Versionen entfernt.
Hinweis: Ersetzen Sie die Upgrade-ID durch Ihre eigene GUID
ProductVersionnur drei Versionsfelder. Daher wird das vierte Feld überhaupt nicht verglichen. Siehe den Hinweis unter VersionMin und VersionMax in msdn.microsoft.com/en-us/library/aa372379(VS.85).aspx
Die folgende Syntax verwende ich für größere Upgrades:
<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 feststellte, gibt es andere Orte, an denen die RemoveExistingProducts abhängig von den gewünschten Optimierungen geplant werden können. Beachten Sie, dass die PUT-GUID-HERE identisch sein muss.
<InstallExecute After="RemoveExistingProducts" />. Ihr Beispiel hat dies nicht - bedeutet das, dass das Buch falsch ist?
Das Upgrade-Element im Product-Element führt in Kombination mit der richtigen Planung der Aktion die Deinstallation durch, nach der Sie suchen. Stellen Sie sicher, dass Sie die Upgrade-Codes aller Produkte auflisten, 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 Sie, wenn Sie mit Ihren Builds vorsichtig sind, verhindern können, dass Personen versehentlich eine ältere Version Ihres Produkts über eine neuere installieren. Dafür ist das Feld Maximum gedacht. Wenn wir Installationsprogramme erstellen, setzen wir UpgradeVersion Maximum auf die zu erstellende Version, aber IncludeMaximum = "no", um dieses Szenario zu verhindern.
Sie haben die Wahl zwischen der Planung von RemoveExistingProducts. Ich bevorzuge es nach InstallFinalize zu planen (anstatt nach InstallInitialize, wie andere empfohlen haben):
<InstallExecuteSequence>
<RemoveExistingProducts After="InstallFinalize"></RemoveExistingProducts>
</InstallExecuteSequence>Dadurch bleibt die vorherige Version des Produkts installiert, bis die neuen Dateien und Registrierungsschlüssel kopiert wurden. Auf diese Weise kann ich Daten von der alten auf die neue Version migrieren (Sie haben beispielsweise die Speicherung von Benutzereinstellungen aus der Registrierung in eine XML-Datei umgestellt, möchten jedoch höflich sein und deren Einstellungen migrieren). Diese Migration wird in einer verzögerten benutzerdefinierten Aktion unmittelbar vor InstallFinalize durchgeführt.
Ein weiterer Vorteil ist die Effizienz: Wenn Dateien unverändert vorhanden sind, kopiert Windows Installer sie nicht erneut, wenn Sie nach InstallFinalize planen. Wenn Sie nach InstallInitialize planen, wird zuerst die vorherige Version vollständig entfernt und dann die neue Version installiert. Dies führt zu unnötigem Löschen und erneuten Kopieren von Dateien.
Weitere Planungsoptionen finden Sie im Hilfethema RemoveExistingProducts in MSDN. Diese Woche lautet der Link: http://msdn.microsoft.com/en-us/library/aa371197.aspx
RemoveExistingProductswurde nachher geplant InstallFinalizeund DLLs wurden nicht aktualisiert, da AssemblyVersion unverändert blieb, andere Felder wie AssemblyProduct jedoch. Ich habe nicht auf Gedeih und Verderb der Datei Vergleichsroutine sein wollen - ich will nur die vorherige App GONE
Fragen Sie dies möglicherweise besser in der Mailingliste der WiX-Benutzer .
WiX wird am besten verwendet, wenn Sie genau wissen, was Windows Installer tut. Möglicherweise möchten Sie " The Definitive Guide to Windows Installer " herunterladen .
Die Aktion, mit der ein vorhandenes Produkt entfernt wird, ist die Aktion RemoveExistingProducts . Da die Konsequenzen dessen, was es tut, davon abhängen, wo es geplant ist - nämlich ob ein Fehler dazu führt, dass das alte Produkt neu installiert wird und ob unveränderte Dateien erneut kopiert werden - müssen Sie es selbst planen.
RemoveExistingProductsverarbeitet <Upgrade>Elemente in der aktuellen Installation und @Idordnet das Attribut dem UpgradeCode(im <Product>Element angegebenen) aller auf dem System installierten Produkte zu. Das UpgradeCodedefiniert eine Familie verwandter Produkte. Alle Produkte mit diesem UpgradeCode, deren Versionen in den angegebenen Bereich fallen und in denen das UpgradeVersion/@OnlyDetectAttribut vorhanden ist no(oder weggelassen wird), werden entfernt.
Die Dokumentation für RemoveExistingProductsErwähnungen zum Festlegen der UPGRADINGPRODUCTCODEEigenschaft. Dies bedeutet, dass der Deinstallationsprozess für das zu entfernende Produkt diese Eigenschaft erhält, deren Wert der Product/@Idfür das zu installierende Produkt ist.
Wenn Ihre ursprüngliche Installation keine enthielt UpgradeCode, können Sie diese Funktion nicht verwenden.
Ich habe diese Website verwendet, um die Grundlagen des WiX-Upgrades zu verstehen:
http://wix.tramontana.co.hu/tutorial/upgrades-and-modularization
Danach habe ich ein Beispielinstallationsprogramm erstellt (eine Testdatei installiert) und dann das Upgrade-Installationsprogramm erstellt (2 Beispieltestdateien installiert). Dies gibt Ihnen ein grundlegendes Verständnis der Funktionsweise des Mechanismus.
Und wie Mike in dem Buch von Apress, "The Definitive Guide to Windows Installer", sagte, hilft es Ihnen zu verstehen, aber es ist nicht mit WiX geschrieben.
Eine andere Seite, die ziemlich hilfreich war, war diese:
Ich habe die WiX- Dokumentation gelesen , Beispiele heruntergeladen, aber ich hatte immer noch viele Probleme mit Upgrades. Kleinere Upgrades führen keine Deinstallation der vorherigen Produkte durch, obwohl die Möglichkeit besteht, diese zu deinstallieren. Ich verbrachte mehr als einen Tag mit Nachforschungen und stellte fest, dass WiX 3.5 ein neues Tag für Upgrades einführte. Hier ist die Verwendung:
<MajorUpgrade Schedule="afterInstallInitialize"
DowngradeErrorMessage="A later version of [ProductName] is already installed. Setup will now exit."
AllowDowngrades="no" />Der Hauptgrund für die Probleme war jedoch, dass in der Dokumentation angegeben ist, dass die Parameter " REINSTALL = ALL REINSTALLMODE = vomus " für kleinere und kleine Upgrades verwendet werden sollen. Es heißt jedoch nicht, dass diese Parameter für größere Upgrades VERBOTEN sind - sie funktionieren einfach nicht mehr. Sie sollten sie daher nicht für größere Upgrades verwenden.
Ich würde vorschlagen, sich Alex Shevchuks Tutorial anzuschauen. Er erklärt das "Haupt-Upgrade" über WiX anhand eines guten praktischen Beispiels unter Von MSI zu WiX, Teil 8 - Haupt-Upgrade .
Eine wichtige Sache, die ich in den Tutorials für eine Weile verpasst habe (gestohlen von http://www.tramontana.co.hu/wix/lesson4.php ), führte zu den Fehlern "Eine andere Version dieses Produkts ist bereits installiert":
* Kleine Updates bedeuten kleine Änderungen an einer oder mehreren Dateien, bei denen die Änderung keine Änderung der Produktversion (major.minor.build) rechtfertigt. Sie müssen auch die Produkt-GUID nicht ändern. Beachten Sie, dass Sie die Paket-GUID immer ändern müssen, wenn Sie eine neue MSI-Datei erstellen, die sich in jeder Hinsicht von den vorherigen unterscheidet. Das Installationsprogramm verfolgt Ihre installierten Programme und findet sie, wenn der Benutzer die Installation mithilfe dieser GUIDs ändern oder entfernen möchte. Die Verwendung derselben GUID für verschiedene Pakete verwirrt den Installer.
Kleinere Upgrades kennzeichnen Änderungen, bei denen sich die Produktversion bereits ändert. Ändern Sie das Versionsattribut des Produkt-Tags. Das Produkt bleibt unverändert, sodass Sie die Produkt-GUID nicht ändern müssen, sondern natürlich eine neue Paket-GUID erhalten.
Wichtige Upgrades bedeuten wesentliche Änderungen wie den Wechsel von einer Vollversion zur anderen. Ändern Sie alles: Versionsattribut, Produkt- und Paket-GUIDs.
Ich verwende die neueste Version von WiX (3.0) und konnte das oben genannte nicht zum Laufen bringen. 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 mit der GUID übereinstimmen sollte, die Sie in der UpgradeCode-Eigenschaft des Produkts definiert haben.
Unten hat für mich gearbeitet.
<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>Stellen Sie sicher, dass der UpgradeCode im Produkt mit der ID im Upgrade übereinstimmt.
Dies ist, was für mich funktioniert hat, auch mit der Hauptnote DOWN :
<Wix ...>
<Product ...>
<Property Id="REINSTALLMODE" Value="amus" />
<MajorUpgrade AllowDowngrades="yes" />