Tag Archives for WiX

WiX 4 in Vagrant Maschine installieren

WiX 4 benötigt .NET SDK 6 oder höher. Das .NET SDK per Shell Provisioner zu installieren ist aber nicht ganz offensichtlich, was primär an zweierlei liegt:

MS möchte .NET gerne per winget installieren, was eine AppStore-App ist (heißt das so?), die per Provisioner selbst nach der abenteuerlichen Installation der Dependencies nicht verfügbar ist:

Program ‘winget.exe’ failed to run: The file cannot be accessed by the systemAt C:\tmp\vagrant-shell.ps1:1 char:1

– vermutlich liegt der Grund irgendwo hier, hier oder hier. Keine Ahnung, Windows halt 🤷🏼‍♂️

Wenn man .NET dann anders installiert, werden die Umgebungsvariablen nicht mit gesetzt m( Na ja, long story short:

Mit dotnet-install.ps1 von hier; zum Einsatz kommt StefanScherer/windows_10. Der Reboot am Ende sollte imho nicht notwendig sein, aber ohne findet er weder wix.exe, noch dotnet.exe. Windows halt 🤷🏼‍♂️

WiX: Escape echo

CustomAction führt ein Kommando aus, und das ist bspw. ein Shell-Befehl. In diesem Fall ein echo in eine Datei:

Will man als Teil von “foobar” jetzt Sonderzeichen mit ausgeben, muss man XML-, WiX-/MSI-, und CMD-Escaping kombinieren – oder man hält sich einfach eine Waffe an den Kopf, das geht schneller:

  • " gibt " aus, & ein & – so weit, so klar. Wenn man davon absieht, dass & eigentlich auch ein CMD-Steuerzeichen ist 🤷🏼‍♂️
  • ^&lt; gibt ein < aus, ^&gt; ein > (man beachte die ^, via)
  • [\[] gibt [ aus, [\]] ein ] (via)

WiX: Install features options

Das Feature-Element hat einige UI-relevante Attribute, die nicht selbsterklärend sind:

  • Absent='disallow' schaltet “The feature will not be installed” aus – wie man für mandatorische Features das Dropdown insgesamt deaktiviert, weiß ich nicht. Ja, man kann das ganze Feature verstecken (Display='hidden'), aber nicht nur das Dropdown 🤷🏻‍♂️
  • AllowAdvertise='no' schaltet “The feature will be installed when needed” aus
  • “The feature and all of its subfeatures will be installed locally” (in früheren Versionen auch “Entire feature will be installed on local hard drive”) kann laut Internet nicht entfernt werden… andere Quellen legen nahe, dass man das über die Subfeatures und Komponenten steuert, aber ich hatte damit keinen Erfolg.

WiX: Upgrade Pitfalls

Art des Upgrades

tl;dr: MajorUpgrade ab der initialen Version!

Folgendes Szenario: Ich baue mit WiX einen MSI-Installer für meine Software. Die Software hat die Version 1.0. Nun möchte ich meine Software auf v1.1 upgraden. Was tun?

WiX bietet mehrere Möglichkeiten, namentlich “Major Upgrades”, “Minor Upgrades”, sowie “Small Updates”, die sich ungefähr so definieren:

  • Small Updates: Quasi ein Patch vorhandener Files, erfordert nicht (zwingend?) eine Änderung der Versionsnummer
  • Minor Upgrade: Aktualisiert bestehende Files ohne die vorhandene Software zu deinstallieren. Kann aber Features oder Komponenten hinzufügen. Erfordert neue (=höhere) Versionsnummer
  • Major Upgrade: “Deinstalliert das Produkt und installiert es neu”, erfordert neue (=höhere) Versionsummer und eine neue Product.Id (Achtung: Product.UpgradeCode “bleibt immer unverändert”)

Liest sich, als würde man meistens ein Minor Upgrade wollen. Internet sagt allerdings das Gegenteil, die Literatur* sieht Major Upgrades als “easier to implement than any other option” an, und last but not least empfiehlt WiX selbst:

When creating an .msi-based installer, you are strongly encouraged to include logic that supports Windows Installer major upgrades.

Was dabei nie so richtig, richtig klar wird (teilweise wird implizit das Gegenteil angedeutet): Beinhaltet nicht bereits Version 1.0 MajorUpgrade (sondern bspw. erst das erste Upgrade), dann funktioniert quasi nichts:

  • v1.1 wird nicht als Update erkannt, sondern parallel installiert!
  • Conditions funktionieren deshalb ebenfalls nicht wie erwartet, es gilt der Pfad wie bei Erstinstallation
  • Downgrades werden nicht verhindert, weil ja beides parallel installiert wird
  • …
  • In anderen Worten: Eine Installation, deren Installer nicht MajorUpgrade enthielt, wird von Upgrade/Downgrade-Logik komplett ignoriert!

Warum das dann nicht mandatorisch ist, wird wohl Microsofts Geheimnis bleiben.

*Nick Ramirez, “WiX 3.6: A Developer’s Guide to Windows Installer XML”, Seite 342

“Scheduling”

Per default deinstalliert ein MajorUpgrade die alte Version und installiert dann die neue. Das kann problematisch sein, denn ein Upgrade (engl. für “Verbesserung”, “Aufrüstung”!) sollte ja bspw. Konfigurationsdaten usw. behalten. Da hilft das Scheduling-Attribut:

sorgt dafür, dass bestehende Dateien (und in diesem Fall auch Services) erhalten bleiben. Es wird quasi definiert, wann das bestehende Produkt entfernt werden soll, und afterInstallExecute sagt “nach der Installation des Upgrades” – natürlich wird dann nur noch entfernt, was in v1.1 nicht mehr benötigt wird.

Achtung: Das setzt offenbar die Erkennung außer Kraft, die eine Neuinstallation derselben Version verhindert 🙄

Conditions

Bestimmte Schritte des Installers sollen nur bei Erstinstallation ausgeführt werden (etwa die Konfiguration durch den User, die Installation eines Services, …). Dafür gibt es Conditions, bzw. verschiedene States, auf die man prüfen kann – und das ist ziemlich unübersichtlich. Ich beschränke mich an dieser Stelle auf einen Stackoverflow-Post, der gute, sprechende Aliase definiert:

Update

Ein Kind von Component sollte immer KeyPath="yes" gesetzt bekommen. Selbst, wenn es nur ein Kind gibt, aber insbesondere bei mehreren. Daran wird entscheiden, welches die maßgebliche Datei ist, die vorhanden (und aktuell) sein muss, um “muss (re-)installiert werden” zu entscheiden.