Aktualisieren Sie einzelne Features im WIX Feature-Baum, ohne andere Features zu deinstallieren oder zu aktualisieren

8

Ich versuche ein Setup-Projekt mit WIX zu erstellen, das mir die Installation mehrerer Features eines einzelnen Produkts ermöglicht. Wie kann ich eine der installierten Funktionen aktualisieren (unabhängig von den anderen installierten Funktionen), ohne die anderen Funktionen in der Feature-Struktur neu installieren zu müssen?

Ich möchte zum Beispiel ein Projekt (das zurück zu HelloWolrd geht) namens HelloWolrd haben, welches (Überraschung) "Hello world!" auf dem Bildschirm. Nehmen wir an, ich habe drei dieser Hello World-Anwendungen, Hello World 1, Hello World 2 und Hello World 3. Jedes von ihnen druckt respektvoll auf dem Bildschirm Hello World 1, 2 oder 3. Was ich möchte, ist ein MSI zu erstellen, das standardmäßig alle drei dieser "Features" installiert, aber auch jedes Feature zu einem späteren Zeitpunkt einzeln aktualisieren kann.

Hier ist mein Layout meiner Lösung:

Lösungs-Explorer http://img12.imageshack.us/img12/5671/solutionexplorerm.jpg

Meine WIX-Produkt.wxs-Datei sieht folgendermaßen aus:

%Vor%

Nun, wenn dies erstellt wird, werden die Features wie erwartet installiert. Wenn Sie jedoch eine Änderung an HelloWorld1.vb vornehmen und neu kompilieren, möchte ich, dass nur dieses Feature (nicht alle) neu installiert (aktualisiert) werden kann.

Wenn ich eine Datei aktualisiere und die Lösung neu anlege, dann versuche, die MSI zu installieren, bekomme ich diesen Fehler:

MSI-Fehler http://img696.imageshack.us/img696/849/anotherversionisinstall.jpg

Ich habe meinen Code aktualisiert, um die Deinstallation der Features zu ermöglichen und die Verwendung von Upgrade-Codes zu ermöglichen, aber alle Features wurden deinstalliert und alle neu installiert.

- Real-World-Anwendung -

Die reale Anwendung ist ein großes Softwarepaket, das mehrere unterstützende Anwendungen benötigt, die regelmäßig als Dienste / geplante Aufgaben ausgeführt werden. Ich würde gerne die Installation dieser unterstützenden Apps in einem MSI bekommen, was uns erlaubt, keinen solchen Alptraum zu haben, jede einzelne Exe individuell auszurollen. Ich weiß, dass, wenn wir ein Update auf eine der exe's haben, wir diese EXE nur manuell kompilieren und ausrollen könnten, aber ich würde das gerne auf vollständig reproduzierbare Weise machen.

Jede Hilfe würde geschätzt werden,

Danke!

BEARBEITEN:

Ich habe die Quelle zum Herunterladen aus Google Code hinzugefügt. Nochmals vielen Dank!

    
Scott 16.11.2009, 18:52
quelle

2 Antworten

12

Ich habe das herausgefunden und dachte, ich würde die Antwort hier veröffentlichen, um sie später für andere zu lesen. Also habe ich das Problem vollständig erklärt, ich werde tiefer ins reale Szenario einsteigen.

Wir haben eine ziemlich große Software, die mehrere unterstützende Anwendungen benötigt, die auf verschiedenen Servern laufen. Unser derzeitiges Fortschreiten von Upgrades macht es mittelmäßig schwierig, Code auf zuverlässige Weise zu aktualisieren. Momentan verwenden wir selbstextrahierende EXEs, um unseren Code auf die verschiedenen Server zu bringen. Das Problem tritt auf, wenn wir eine so große Anzahl unterstützender Anwendungen haben, dass es schwierig wird, sicherzustellen, dass die Anwendungen korrekt mit den richtigen Konfigurationseinstellungen usw. installiert wurden. Um dieses Problem zu lösen, prüfen wir, ob es möglich ist, jeden einzelnen zu komprimieren Bei den unterstützenden Anwendungen erstellen wir ein einzelnes Installationsprogramm (MSI), mit dem das Infrastrukturteam einen bestimmten Satz unterstützender Anwendungen für jede bestimmte Maschine installieren kann. Wenn wir eine größere Änderung vornehmen (zum Beispiel von 1.0 auf 2.0), werden wir eine vollständige Upgrade-Installation durchführen (dh alle Dienste / Prozesse müssen gestoppt, nicht installiert, installiert und gestartet werden). Wenn wir eine geringfügige Änderung vornehmen, wir möchten nur die betroffenen Dienste / Prozesse anhalten und neu installieren, ohne andere Anwendungen zu berühren. Nun, genug von mir zu wühlen, können wir die Lösung:

Ich habe die WIX Product.wxs modifiziert, um die Verknüpfungen zu entfernen, da wir sie in unserem Szenario nicht wirklich brauchen. Hier ist die aktualisierte wxs-Datei:

%Vor%

Nun werden wir zusammen mit unseren kleineren Upgrades Patches für unsere Komponenten veröffentlichen.

Nehmen wir beispielsweise an, wir haben ein ProductA, das aus drei Komponenten besteht: 1,2 und 3. Diese drei Komponenten müssen entweder als Dienste oder als geplante Aufgaben ausgeführt werden. Aufgrund der Beschaffenheit unseres Produkts können wir nicht alle unsere Services herunterfahren, um eine unserer Komponenten zu aktualisieren oder zu reparieren. Also, wenn wir nach der Installation von Version 1.0 einen Fehler in Komponente 2 gefunden haben, aber nicht wollen, dass 1 oder 3 von dem Fix betroffen ist, der auf diesen Fehler angewendet wird, werden wir einen Patch für Komponente 2 veröffentlichen, somit ist nur die Komponente 2 betroffen.

Für unser kurzes Beispiel oben verwenden wir HelloWorld1, HelloWorld2 und HelloWorld3 als unsere 3 Komponenten in unserer Softwareanwendung. Der Gedanke ist, dass wir in der Lage sein sollten, alle drei mit einem MSI zu installieren, aber dann jedes unabhängig zu aktualisieren, ohne dass es irgendwelche der anderen installierten Komponenten beeinflusst.

Um dies zu demonstrieren, habe ich oben die drei Konsolenanwendungen erstellt, die "Hello World 1!", "Hello World 2!" und "Hello World 3!" anzeigen. Dann, nachdem wir das erste MSI veröffentlicht haben, sagen wir, dass wir einen "Bug" finden, der es erfordert, dass HelloWorld1 "Hello World 1! Updated" sagt. stattdessen. Hier ist, was wir tun werden, um dies zu simulieren:

  1. Erstellen Sie die Product.wixobj, indem Sie diesen Befehl an der Eingabeaufforderung ausführen:
    candle.exe Product.wxs
    Bitte beachten Sie, dass das Wix-Installationsverzeichnis sein sollte, um die candle.exe oder einen der WIX-Befehle aufzurufen in Ihrer PATH-Variable. ( Kurzanleitung zur Aktualisierung der PATH-Umgebungsvariablen ) Führen Sie die Befehle bitte im selben Verzeichnis wie Ihr Product.wxs aus Datei.
  2. Erstellen Sie die erste Version Ihres Produkts (sagen wir 1.0):
    light.exe Product.wixobj -out ProductA-1.0.msi
  3. Finde nun einen Fehler (ändere die Ausgabe von HelloWorld1 auf "Hallo Welt 1! Aktualisiert") und aktualisiere die Assemblyversion und die Dateiversion . Dies ist wichtig, da WIX die EXEs unterscheiden kann.
  4. Führen Sie den gleichen Befehl wie Schritt eins aus (für ein gutes Maß):
    candle.exe Product.wxs
  5. Führen Sie fast denselben Befehl wie Schritt zwei aus:
    light.exe Product.wixobj -out ProductA-1.1.msi
    Beachten Sie, dass dies Version 1.1 statt 1.0 ist (dies ist die MSI mit unserem aktualisierten Code). Wir möchten jedoch nicht nur das installieren, weiterlesen.
  6. Hier ist der spaßige Teil, wir erhalten den Unterschied in den beiden MSIs mit dem folgenden Befehl:
    torch.exe -p -xi ProductA-1.0.wixpdb ProductA-1.1.wixpdb -out Diff.WixMst
  7. Jetzt erstellen wir die Patch-Datei von diesem (Patch.wxs wird unten erklärt):
    candle.exe Patch.wxs
  8. Wir werden nun die WixMsp-Datei mit diesem Befehl erstellen:
    light.exe Patch.wixobj -out Patch.WixMsp
  9. Und jetzt, der spaßige Teil. Erstellen Sie die MSP-Datei mit diesem Befehl:
    pyro.exe Patch.WixMsp -out Patch.msp -t RTM Diff.Wixmst

Wenn nun alles nach Plan lief, sollten Sie zwei MSIs und eine MSP-Datei haben. Wenn Sie die erste MSI (ProductA-1.0.msi) installieren und HelloWorld1.exe ausführen, sollten Sie die Nachricht "Hello World 1!" Sehen. Nur zum Spaß (und Beispiel), führen Sie beide anderen Anwendungen und lassen Sie sie laufen (ich baute einen Stop, um sie offen zu halten). Schließen Sie HelloWorld1.exe, da wir nun das Update für diese Exe anwenden werden, aber wir werden HelloWorld2.exe oder HelloWorld3.exe nicht beeinflussen. Wenn Sie jetzt die Datei MSP (Patch.msp) installieren und anschließend HelloWorld1.exe ausführen, wird die aktualisierte Nachricht "Hello World 1! Updated" angezeigt."

Nun zu der magischen Patch.wxs-Datei:

%Vor%

Sieht nicht nach viel aus, oder? Nun, die interessantesten Teile sind diese:

  1. <PatchBaseline Id="RTM"/> - Wenn Sie sich erinnern, wird dies bei der Erstellung des Patches msi verwendet. Auf den "RTM" wird im letzten Schritt oben verwiesen: -t RTM - Diese müssen übereinstimmen.
  2. <ComponentRef Id="HelloWorld1Component"/> - Dies verweist den Patch auf die korrekte zu aktualisierende Komponente, in unserem Fall HelloWorld1Component.

Wenn Sie schon einmal herumgesucht haben, scheint der obige Code bekannt zu sein, weil er aus Peter Marcus Blog : WiX: Erstellen eines Patches mit dem neuen Patch-Build-System - Teil 3

Ich verließ mich auch stark auf Alex Shevchuks Blog : Von MSI zu WiX, Teil 8 - Major Upgrade

Wenn Sie sich fragen: "Wow, das sind eine Menge Schritte, warum sollte jemand so viele Schritte machen?", denken Sie bitte daran, dass Sie, sobald die harte Arbeit (oben) erledigt ist, diese in Ihre Integrationsroutine verschieben müssen . Das stimmt, integrieren, integrieren, integrieren ! Wie machst Du das? Nun, das ist ein bisschen mehr Forschung und vielleicht ein Blogbeitrag? - Wahrscheinlich. Um Sie auf den richtigen Fuß zu bringen, hier ist ein großartiger Artikel über Automatisieren Sie Releases mit MSBuild und Windows Installer XML .

Wow, ich hoffe, du hast das alles (zu zweit) gelesen und viel gelernt. Ich hoffe, dass das jemand anderem als mir hilft.

Danke!

    
Scott 18.11.2009, 00:16
quelle
0

Hört sich an, als ob Sie das Upgrade-Szenario herausgefunden haben, jetzt müssen Sie nur herausfinden, Platzierung von RemoveExistingProducts in einem MSI-Hauptupgrade , damit Features nicht erneut installiert werden, wenn sie nicht geändert wurden:

    
saschabeaumont 16.11.2009 22:51
quelle