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:

<MajorUpgrade Schedule="afterInstallExecute" DowngradeErrorMessage="A newer version of [ProductName] is already installed."/>

1	<MajorUpgrade Schedule="afterInstallExecute" DowngradeErrorMessage="A newer version of [ProductName] is already installed."/>

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:

<SetProperty After="FindRelatedProducts" Id="FirstInstall" Value="true">
  NOT Installed AND NOT WIX_UPGRADE_DETECTED AND NOT WIX_DOWNGRADE_DETECTED
</SetProperty>
<SetProperty After="SetFirstInstall" Id="Upgrading" Value="true">
  WIX_UPGRADE_DETECTED AND NOT (REMOVE="ALL")
</SetProperty>
<SetProperty After="RemoveExistingProducts" Id="RemovingForUpgrade" Sequence="execute" Value="true">
  (REMOVE="ALL") AND UPGRADINGPRODUCTCODE
</SetProperty>
<SetProperty After="SetUpgrading" Id="Uninstalling" Value="true">
  Installed AND (REMOVE="ALL") AND NOT (WIX_UPGRADE_DETECTED OR UPGRADINGPRODUCTCODE)
</SetProperty>
<SetProperty After="SetUninstalling" Id="Maintenance" Value="true">
  Installed AND NOT Upgrading AND NOT Uninstalling AND NOT UPGRADINGPRODUCTCODE
</SetProperty>

NOT Installed AND NOT WIX_UPGRADE_DETECTED AND NOT WIX_DOWNGRADE_DETECTED

</SetProperty>

WIX_UPGRADE_DETECTED AND NOT (REMOVE="ALL")

</SetProperty>

(REMOVE="ALL") AND UPGRADINGPRODUCTCODE

</SetProperty>

Installed AND (REMOVE="ALL") AND NOT (WIX_UPGRADE_DETECTED OR UPGRADINGPRODUCTCODE)

</SetProperty>

Installed AND NOT Upgrading AND NOT Uninstalling AND NOT UPGRADINGPRODUCTCODE

</SetProperty>

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.

Kommentare, die die Welt nicht braucht – LXX

Watt, das habe ich noch nie gepostet??

🎶 Immer wenn ich traurig bin, lese ich diese Commit Message 🎵
(Und den Zusatz zur Autorin)

bash: Ergebnis iterieren

Hier: Über alle angeschlossenen Geräte

#!/usr/bin/env bash

input="$(idevice_id --list)"
IFS=$'\n' read -rd '' -a deviceIds <<<"$input"

for deviceId in "${deviceIds[@]}"
  do
    echo "device id: ${deviceId}"
  done

#!/usr/bin/env bash

input="$(idevice_id --list)"

IFS=$'\n' read -rd '' -a deviceIds <<<"$input"

for deviceId in "${deviceIds[@]}"

echo "device id: ${deviceId}"

done

mit

Kommentare, die die Welt nicht braucht – LXIX

Allerdings:

Ember: Unit-test Promise

import {moduleFor, test} from 'ember-qunit';
import RSVP from 'rsvp';
import wait from 'ember-test-helpers/wait';

moduleFor('controller:login-view', 'Unit | Controller | Login view', {
    needs: ['service:session']
});

test('some description', function (assert) {
  let ctrl = this.subject({
    session: {
      login() {
        return new RSVP.Promise((resolve, reject) => {
          reject(/* ... */)
        })
      }
    }
  });
  ctrl.send('someLoginAction');
  wait().then(() => {
    // assert goes here
  });
});

import {moduleFor, test} from 'ember-qunit';

import RSVP from 'rsvp';

import wait from 'ember-test-helpers/wait';

moduleFor('controller:login-view', 'Unit | Controller | Login view', {

needs: ['service:session']

});

test('some description', function (assert) {

let ctrl = this.subject({

session: {

return new RSVP.Promise((resolve, reject) => {

reject(/* ... */)

})

}

});

ctrl.send('someLoginAction');

wait().then(() => {

// assert goes here

});

Quelle

Kommentare, die die Welt nicht braucht – LXVIII

Ich übersetze:

Software-Forensiker: “Unser Code ist sehr alt und so schlecht, dass ihn niemand mehr versteht. Wenn wir ihn einsetzen, funktioniert die Hälfte nicht. Und Sie müssen uns erklären, warum!”
Maintenance Engineer: “Der beschriebene Code muss auch zukünftig weiter so funktionieren.”
Qualitätssicherung im Softwareentwicklungsprozess: “Sie wären zukünftig der Schuldige, falls die Codequalität unserer n+1 Entwickler – völlig wider Erwarten – weiterhin so schlecht bleibt, wie sie offenbar seit signifikant vielen Jahren ist.”

Nein, Danke.

Kommentare, die die Welt nicht braucht – LXVII

“OK, der Internet Explorer war schlecht, zugegeben. Aber jetzt gibt es Edge, der ist total fantastisch!!1”

Fun Fact am Rande: Der Edge hat in seinem Menü einen Punkt “Open with Internet Explorer” 🙄

Gradle: ordered dependsOn

Statt

task foo(dependsOn: [bar1, bar2, bar3]) {
    // ...
}

task foo(dependsOn: [bar1, bar2, bar3]) {

// ...

}

besser:

task foo() {
    def tasks = [bar1, bar2, bar3]
    for (int i = 0; i < tasks.size() - 1; i++) {
        tasks[i + 1].mustRunAfter(tasks[i])
    }
    dependsOn(tasks)

    // ...
}

task foo() {

def tasks = [bar1, bar2, bar3]

for (int i = 0; i < tasks.size() - 1; i++) {

tasks[i + 1].mustRunAfter(tasks[i])

}

dependsOn(tasks)

// ...

}

Kommentare, die die Welt nicht braucht – LXVI

Sie können möglicherweise immer noch Elemente wiederherstellen, die aus diesem Ordner gelöscht wurden.
(0 Elemente wiederherstellbar)
[Gelöschte Elemente wiederherstellen] [Weitere Informationen]

Und: Ja, kein Schließen oder “Cancel”-Button. Danke, Outlook 🙏

(Klick für groß)

Seleniums “Info-Bar” verschiebt Click-Koordinaten?

Der Chrome zeigt während des Tests

Chrome is being controlled by automated test software

an? Das kann Dir die Click-Events verschieben (um etwa 100px nach oben) 🙄 Fix:

ChromeOptions options = new ChromeOptions();
options.addArguments("disable-infobars");
driver = new ChromeDriver(options);

ChromeOptions options = new ChromeOptions();

options.addArguments("disable-infobars");

driver = new ChromeDriver(options);

UPDATE: Ein paar Tage später sind die Koordinaten wieder verschoben; lag also nicht (nur?) daran!

crusy.net

♪ Commit ins Abenteuerland ♫

Category Archives for Coding

WiX: Upgrade Pitfalls

Art des Upgrades

“Scheduling”

Conditions

Update

Kommentare, die die Welt nicht braucht – LXX

bash: Ergebnis iterieren

Kommentare, die die Welt nicht braucht – LXIX

Ember: Unit-test Promise

Kommentare, die die Welt nicht braucht – LXVIII

Kommentare, die die Welt nicht braucht – LXVII

Gradle: ordered dependsOn

Kommentare, die die Welt nicht braucht – LXVI

Seleniums “Info-Bar” verschiebt Click-Koordinaten?