WiX Tricks und Tipps

Question

Wir verwenden schon seit einiger Zeit WiX und trotz der üblichen Schwierigkeiten bei der Benutzerfreundlichkeit läuft es recht gut. Was ich suche, sind nützliche Ratschläge zu folgenden Themen:

• Einrichten eines WiX-Projekts (Layout, Verweise, Dateimuster)
• WiX in Lösungen und Build-/Release-Prozesse integrieren
• Installationsprogramme für neue Installationen und Upgrades konfigurieren
• Irgendwelche nützlichen WiX-Tricks, die Sie teilen möchten

Answer 1

Druck-EULA von Wix3.0 und höher

1) Wenn Sie Ihren Wix-Quellcode kompilieren, muss das light.exe die WixUIExtension.dll in der Befehlszeile referenzieren. Verwenden Sie den Befehlszeilenschalter -ext dafür.

2) Wenn beim Hinzufügen der Referenz zur WixUIExtension.dll Ihr Projekt nicht kompiliert werden kann, liegt dies höchstwahrscheinlich an Kollisionen von Dialog-IDs, d.h. Ihr Projekt verwendete dieselben IDs von Dialogen wie einige Standarddialoge in WixUIExtension.dll, geben Sie Ihren Dialogen unterschiedliche IDs. Dies ist ein ziemlich häufiges Problem.

3) Ihr Lizenzdialog muss eine ScrollableText-Steuerung mit der ID "LicenseText" haben. Wix sucht genau nach diesem Steuerelementnamen, wenn es druckt.

und ein PushButton, der auf die benutzerdefinierte Aktion verweist

    1

4) Definieren Sie die benutzerdefinierte Aktion mit der Id="PrintEula" wie folgt:

Hinweis: Der BinaryKey ist bei Wix3.0 im Vergleich zu Wix2.0 unterschiedlich und muss genau "WixUIWixca" (Groß- und Kleinschreibung beachten) sein.

Wenn der Benutzer auf die Schaltfläche drückt, wird ihm der Standard-Druckerdialog angezeigt und er kann von dort aus drucken.

Answer 2

Komponenten, die einzeln gepatcht werden können, sollten in ihren eigenen Fragmenten platziert werden

Dies gilt sowohl für die Erstellung von Produktinstallateuren als auch für Patches. Wenn Sie eine Komponente in einem Fragment einschließen, müssen Sie alle Komponenten in diesem Fragment einschließen. Wenn Sie beim Erstellen eines Installers eine Komponentenreferenz vergessen, erhalten Sie einen Verknüpfungsfehler von light.exe. Wenn Sie jedoch einen Patch erstellen und eine einzelne Komponentenreferenz in einem Fragment einschließen, werden alle geänderten Komponenten aus diesem Fragment in Ihrem Patch angezeigt.

so:

anstatt dieses:

Auch beim Patchen mit Hilfe des Themas "Nutzung von reinem WiX" aus der WiX.chm-Hilfedatei müssen Sie folgendes Verfahren zum Erstellen des Patches verwenden:

torch.exe -p -xi 1.0\product.wixpdb 1.1\product.wixpdb -out patch\diff.wixmst
candle.exe patch.wxs
light.exe patch.wixobj -out patch\patch.wixmsp
pyro.exe patch\patch.wixmsp -out patch\patch.msp -t RTM patch\diff.wixmst

Es reicht nicht aus, nur die Version 1.1 des product.wixpdb zu haben, das mit den Komponenten in separaten Fragmenten erstellt wurde. Stellen Sie daher sicher, dass Sie Ihr Produkt vor dem Versand ordnungsgemäß fragmentieren.

Answer 3

• Wir zeigen die Produktversion irgendwo (winzig) auf dem ersten Bildschirm der GUI an. Denn die Leute tendieren dazu, jedes Mal Fehler bei der Auswahl der richtigen Version zu machen. (Und lassen uns Entwickler ständig lange suchen..)

• Wir haben TFSBuild so eingerichtet, dass es auch Transforms (.mst-Dateien) mit der Konfiguration für unsere verschiedenen Umgebungen generiert. (Wir kennen alle Umgebungen, zu denen wir bereit sind zu deployen).

Da der originale Weblog-Beitrag von Grant Holliday nicht verfügbar ist, habe ich den Inhalt hier kopiert:

---

MSBuild-Aufgabe zum Generieren von MSI-Transformdateien aus XML 11. März 2008

In meinem vorherigen Beitrag habe ich beschrieben, wie Sie MSI-Transform (*.mst)-Dateien verwenden können, um umgebungsspezifische Konfigurationseinstellungen von einem generischen MSI-Paket zu trennen.

Obwohl dies eine gewisse Flexibilität in Ihrer Konfiguration bietet, gibt es zwei Nachteile von Transformdateien:

1. Sie sind ein binäres Format
2. Sie können eine Transformdatei nicht "bearbeiten" oder "anzeigen". Sie müssen sie anwenden oder neu erstellen, um zu sehen, welche Änderungen sie enthält.

Glücklicherweise können wir die Microsoft Windows Installer-Objektbibliothek (c:windowssystem32msi.dll) verwenden, um MSI-"Datenbanken" zu öffnen und Transformdateien zu erstellen.

Dank geht erneut an Alex Shevchuk - From MSI to WiX - Teil 7 - Anpassen der Installation mit Transforms, der uns gezeigt hat, wie man dies mit VbScript erreichen kann. Im Wesentlichen habe ich lediglich Alex' Beispiel genommen und mit Interop.WindowsInstaller.dll eine MSBuild-Aufgabe implementiert. Die MSBuild-Aufgabe

Laden Sie hier den Quellcode & das Beispiel transforms.xml herunter (~7Kb Zip VS2008-Lösung)

---

Answer 4

Verwenden Sie anstelle von ORCA InstEd, ein gutes Tool zur Anzeige von MSI-Tabellen. Außerdem hat es die Möglichkeit, zwei Pakete durch Transform -> Compare To... zu vergleichen.

Zusätzlich ist eine Plus-Version mit zusätzlicher Funktionalität erhältlich. Aber auch die kostenlose Version bietet eine gute Alternative zu Orca.

Answer 5

Registrierung von .NET-Assemblys für COM-Interop mit x86/x64 Kompatibilität

Achtung Dieser Abschnitt ist im Wesentlichen dasselbe wie REGASM Assembly.dll /codebase

In diesem Beispiel passieren ein paar Dinge, also hier ist der Code und ich werde es danach erklären...

Wenn Sie sich fragen, dies ist eigentlich für einen ASCOM-Teleskop-Treiber.

Zunächst habe ich den oben genannten Rat befolgt und einige Plattformvariablen in einer separaten Datei erstellt, Sie können diese im XML verstreut sehen.

Der If-Then-Else-Teil oben beschäftigt sich mit der x86- gegen x64-Kompatibilität. Meine Assembly zielt auf 'Any CPU' ab, also auf einem x64-System muss ich sie zweimal registrieren, einmal im 64-Bit-Register und einmal in den 32-Bit Wow6432Node Bereichen. Das If-Then-Else bereitet mich darauf vor, die Werte werden später in einer foreach-Schleife verwendet. Auf diese Weise muss ich die Registrierungsschlüssel nur einmal erstellen (DRY-Prinzip).

Das Dateielement spezifiziert die tatsächliche Assembly-DLL, die installiert und registriert wird:

Nichts Revolutionäres, aber beachten Sie das Assembly=".net" - dieses Attribut allein würde bewirken, dass die Assembly in den GAC eingefügt wird, was NICHT das ist, was ich wollte. Durch Verwendung des AssemblyApplication-Attributs, das auf sich selbst verweist, verhindere ich einfach, dass Wix die Datei in den GAC einfügt. Jetzt, da Wix weiß, dass es sich um eine .NET-Assembly handelt, kann ich bestimmte Bindungsvariablen in meinem XML verwenden, wie z.B. !(bind.assemblyFullname.filDriverAssembly), um den vollständigen Namen der Assembly zu erhalten.