Ich habe einen ziemlich großen WiX-Installer (250 MB plus) und ich versuche, eine geeignete Upgrade-Strategie zu finden.
Die meisten Dateien im Installationsprogramm ändern sich nicht und wir möchten das gesamte Paket nicht verteilen müssen, wenn nur eine oder zwei Dateien geändert wurden.
Ich habe größere und kleinere Upgrades untersucht und ich gehe davon aus, dass ein größeres Upgrade stattfinden wird, wenn sich die Produkt-ID ändert, solange die Upgrade-ID gleich bleibt und kleinere Upgrade-Patches verwendet werden können, wenn beide Werte beibehalten werden gleich.
Ich habe das Gefühl, dass eine kleine Aktualisierung mit einem Patch die beste Option wäre, um die Fälle zu bearbeiten, in denen sich nur wenige Dateien ändern, und nur das gesamte Installationsprogramm neu zu erstellen, wenn sich eine beträchtliche Anzahl von Dateien ändert.
Ich habe dies mit "fackel" getestet, um eine "wixmst" -Datei basierend auf den Unterschieden zwischen zwei "wixpdb" -Dateien zu erstellen und daraus einen Patch zu erstellen. Ich habe jedoch festgestellt, dass ich nur von einer Version zur anderen patchen kann (z. B. 1.0.0 bis 1.0.1, dann 1.0.1 bis 1.0.2, aber nicht 1.0.0 bis 1.0.2). Ist es möglich, eine Mindestversion für einen Patch anzusprechen und eine darüber liegende Version zu unterstützen?
Patchen ist ein Schmerz, also machen Sie sich auf vieles gefasst, wenn Sie lernen, es zu meistern. Hier ist eine andere Strategie, die für Sie arbeiten könnte. Teilen Sie Ihr MSI in 2 MSI (Microsoft nennt dieses Micropackages). Haben Sie ein Basis-MSI, das den Großteil Ihres Inhalts enthält, der sich voraussichtlich nicht ändert, und ein zweites MSI, das viel kleiner ist und Ihre Dateien enthält, von denen Sie erwarten, dass es eine hohe Abwanderung darstellt.
Dann verwenden Sie Burn ist ein Bootstrapper, um diese zu verketten und zusammen zu deinstallieren. Dies ist ähnlich wie in Visual Studio.
Jetzt können Sie nur größere Upgrades Ihres zweiten MSI versenden.
Ich glaube, dass es möglich ist, das oben beschriebene Szenario zu patchen, solange die Patches nicht deinstallierbar sind. Ein Beispielszenario wäre:
Weitere Informationen zu nicht installierbaren Patches finden Sie in der wix-Dokumentation: Ссылка und die Windows-Dokumentation: Ссылка .
Beachten Sie, dass zum Erstellen von nicht installierbaren Patches bestimmte Einschränkungen gelten und Sie mindestens WiX 3.0 verwenden müssen.
Wie Christopher erwähnt hat, kann Patching ein Schmerz sein. Ich habe festgestellt, dass meine Manager in vielen Fällen nach der Möglichkeit fragen, Patch-Upgrades durchzuführen, wenn alles, was sie wirklich meinen, für den Benutzer in der Lage ist, ein Upgrade ohne manuelle Installation durchzuführen, was durch ein großes Upgrade problemlos erreicht werden kann / p>
Das heißt, wenn Sie Kunden haben, die viele kleine Updates benötigen, die häufig heruntergeladen werden, dann ist das Patchen den zusätzlichen Aufwand wert.
Während Christophers Antwort in der Hinsicht fantastisch ist, dass er den Bootstrapper von wix vorschlägt, würde ich davon abraten, größere Updates für das "High-Churn" -Paket zu machen. Das Problem ist, dass der bootstrapper, nachdem Sie Ihren bootstrapping-Patch gemacht haben, der intern eine große Aktualisierung Ihrer flüchtigen libs in der HighChurn.msi von Version v1.0 zu v1.1 vornimmt, meines Wissens das vorherige nicht neu installieren wird Paket von HighChurn.msi in v1.0.
Es gibt noch einen anderen Weg: Sie können sicherlich Patches erstellen, die auf die Veröffentlichung Ihres Hauptpakets abzielen. Angesichts dessen, was Sie geschrieben haben, bin ich mir nicht ganz sicher, aber wenn Ihr 1.2-Patch nur auf 1.1 angewendet werden kann, dann haben Sie wahrscheinlich Ihren 1.2 nur gegen 1.1 und nicht gegen 1.0 diffamiert.
Hier finden Sie eine praktische Anleitung zum Erstellen von Patches: Ссылка
Folge dieser Anleitung, ersetze Patches ([PatchFamily / @ Supersede]), dadurch wird v1.2 alles, was v1.1 ausgeliefert hat, ungültig machen, also musst du grundsätzlich v1.2 patch v1.0 und nicht v1 machen .1), und fügen Sie dieses Flag dem Patch-Element hinzu, um auf die Hauptversion zu zielen, auch wenn höhere Versionen vorhanden sind: Patch / @ MinorUpdateTargetRTM=" Ja ". Unterscheiden Sie Ihre Patches immer gegen das Release-Installationsprogramm (HighChurn.msi v1.0), niemals gegen das Installationsprogramm, das Sie für ein Patch verwendet haben (HighChurn.msi v1.1).
Es gibt natürlich Situationen, in denen Sie möglicherweise ein bestimmtes Upgrade für Patches benötigen: Ein gut geplantes Fixpack- / Servicepack-Schema, bei dem Patch 1.1.1 beispielsweise das Installieren von Service Pack 1.1 über dem Release 1.0 erfordert / p>
Ein letztes Wort zum Patchen Ihrer flüchtigen Daten (ich nehme hier versionierte Bibliotheken an): Sie sollten vielleicht im Auge behalten, welche Bibliotheken Sie im Patch ersetzen könnten. Dann können Sie Patches mit sehr wenigen Daten erstellen, indem Sie den geänderten Bibliotheken nur eine höhere Version zuweisen. Wenn Sie die Version für alle Ihre Bibliotheken erhöhen, werden alle Bibliotheken gepatcht, was zu größeren Patches führt. Dies könnte einen etwas komplizierteren Build-Workflow erfordern (Gott weiß, dass es für uns getan hat).