MSI installiert nicht alle Dateien, wenn REMEPREVOUSVERSIONS ausgeführt wird

Question

Ich habe einen MSI -Build mit Wix Version 3.

Alle früheren Installateure für das von uns bereitgestellte Produkt funktionierten gut mit der angegebenen Konfiguration (dh: Wenn die vorherige Version vorliegt, entfernen Sie und installieren Sie die neue Version) - die neuen MSIS, die wir erstellen, installieren jedoch nicht alle Dateien, wenn sie durchlaufen der 'erste' Weg.

Wenn wir die vorhandene Installation manuell entfernen und dann die neue Version ausführen, werden alle Dateien installiert - und wenn ich die MSI -Datei in Orca untersuche, werden die Dateien und Funktionen angezeigt und scheinen in Ordnung zu sein.

Wir haben versucht, mit ausführlicher und zusätzlicher Protokollierung eingeschaltet zu laufen (eingeschaltet (/l*vx) Wir können jedoch nur sehen, ob die Dateien nicht registriert und dann installiert werden.

Irgendwelche Gedanken oder Vorschläge? Das treibt uns die Wand hinauf.

Answer 1

Ok, gut mit jemand anderem zu sprechen, wo mir geholfen habe, eine Lösung für das Problem zu finden.

Wir haben die Eigenschaft hinzugefügt REINSTALLMODE und setzen es auf amus. Was bedeutet das?

Standardmäßig ist die Eigenschaft auf omus Dies bedeutet: Neuinstallieren Sie, wenn die Datei fehlt oder älter, die Registrierung für Maschinen- und Benutzer -Bienenstöcke neu schreiben, Verknüpfungen neu installieren. Ändern dies in amus Grundsätzlich sagt: Alle Dateien neu installieren.

Also nicht zu 100% sicher, was die Ursache war - ich vermute, es gab vielleicht seltsame Schlösser oder so, aber eingestellt zu amus Wenn wir keine nachteiligen Auswirkungen haben, bleiben wir dabei.

Danke für die Vorschläge.

(Weitere Details zu dieser Eigenschaft finden Sie hier: MSDN: Eigenschaftseigenschaft neu installieren

Answer 2

Basierend auf der Standard -benutzerdefinierte Aktionssequenz stellt Windows Installer fest, welche Dateien installiert/überschrieben werden müssen, bevor vorhandene Softwareversionen entfernt werden. Windows Installer verwendet den Wert der NeustallMode -Eigenschaft, um zu erfahren, wie Sie Entscheidungen darüber treffen können, wann Dateien überschreiben können. Wenn ReinstallMode ein "O" enthält, werden nur Dateien installiert, bei denen die Version unterschiedlich ist oder die Datei noch nicht vorhanden ist. Nichtverssionierte Dateien werden nur installiert, wenn das geänderte Datum der Datei <= das erstellte Datum ist (dh die Datei wird nicht geändert). Wenn der Neustallmode ein "A" enthält, installiert er immer die Datei, unabhängig von Versions- oder Datumsinformationen, die an vorhandene Dateien angehängt sind.

Was in Ihrem Szenario passiert, ist höchstwahrscheinlich Folgendes:

1. Windows Installer stellt fest, welche Dateien installiert werden sollen. Es entscheidet, dass einige Dateien nicht installiert werden müssen (möglicherweise weil sie bereits existieren und die gleichen oder neueren Versionen wie die im MSI sind).
2. Die vorherige Version der Software wird entfernt, einschließlich der von Windows Installer festgelegten Dateien musste nicht installiert werden.
3. Windows Installer installiert Dateien für die neue Installation, musste jedoch keine Dateien installiert, die nicht installiert werden mussten.

Das Endergebnis ist, dass nach dem Upgrade der Software eine Reihe von Dateien fehlen. Das Einstellen von ReinstallMode = Amus anstelle von Omus wird wahrscheinlich Ihr Problem beheben. Sie sollten jedoch sicherstellen, dass Sie wissen, wie sich dies auf den Rest Ihrer Installation auswirkt. Wenn es Dateien gibt, die Sie nicht überschrieben werden möchten, müssen Sie diese Komponenten markieren, um "niemals zu überschreiben".

Answer 3

Was macht dein <RemoveExistingProducts After=""> Schritt aussehen wie? Es könnte sein, dass das Entfernung nach der Installation ausgeführt wird - und alle Dateien entfernen, die in den vorherigen und aktuellen Versionen gleich waren.

Ich habe mein Installateur aufgestellt <RemoveExistingProducts After="InstallInitialize"> Um sicherzustellen, dass es vor irgendetwas anderem erledigt ist. Ich weiß nicht, ob es richtig ist oder nicht, aber es scheint zu funktionieren.

    <Upgrade Id="$(var.UpgradeCode)">
        <!--Upgrade code found at http://www.nichesoftware.co.nz/blog/200809/upgradable-msi-installations-with-wix -->
        <!-- Detect any newer version of this product-->
        <UpgradeVersion Minimum="$(var.version)" IncludeMinimum="no" OnlyDetect="yes" Language="1033" Property="NEWPRODUCTFOUND" />

        <!-- Detect and remove any older version of this product-->
        <UpgradeVersion Maximum="$(var.version)" IncludeMaximum="yes" OnlyDetect="no" Language="1033" Property="OLDPRODUCTFOUND" />
    </Upgrade>
    <CustomAction Id="PreventDowngrading" Error="Newer version already installed"></CustomAction>
    <InstallExecuteSequence>
        <!-- Prevent Downgrading-->
        <Custom Action="PreventDowngrading" After="FindRelatedProducts">NEWPRODUCTFOUND</Custom>
        <RemoveExistingProducts After="InstallInitialize" />
    </InstallExecuteSequence>
    <InstallUISequence>
        <!-- Prevent Downgrading-->
        <Custom Action="PreventDowngrading" After="FindRelatedProducts">NEWPRODUCTFOUND</Custom>
    </InstallUISequence>

Answer 4

Ich weiß, dass dies ein älterer Thread ist, aber ich habe auf ein ähnliches Problem gestoßen, das nicht von den Lösungen abgedeckt wurde. In meinem Fall hatte ich eine DLL, die eigentlich eine niedrigere Zahl als der Vorgänger war. Diese DLL würde niemals in einer Upgrade -Installation erscheinen. Betrieb

msiexec /i myproduct.msi /l*vx install2.log

und das Überprüfen des Protokolls zeigte, dass die Datei nie installiert wurde. Es wurde einfach nicht im Protokoll als eine der installierten Dateien angezeigt. Der MSI enthielt definitiv die Datei, die beste Beweise dafür, dass eine Reparatur die Datei platzieren würde. Die Explosion des MSI mit verschiedenen Tools zeigte auch die vorhandene Datei. Eine gerade Installation auf einer sauberen Maschine würde immer funktionieren.

Das half nicht:

msiexec /i myproduct.msi REINSTALL=ALL REINSTALLMODE=amus /l*vx install3.log

Ich baue den MSI mit Wix und benutze dieses Skript seit vielen Jahren. Zuletzt haben wir das Skript so festgelegt, dass das alte Verzeichnis in unserer 5.3 -Version vollständig gelöscht wird. Dies hatte auf 5.2 -> 5.3 und 5.3 -> 5.4 Upgrades gearbeitet. Aber mit der 5.5 -Version wurden die DLLs alle mit neuen Versionen der DLLs umgebaut. Die DLL -Projekte wurden in Github gehostet. Das Build-Skript für diese bestimmte DLL wurde als Assembly-Version von '10 .0.0. Das Projekt war bewegt worden, was dazu führte, dass der Kopf zählte von 444 auf 30.

Das WixScript hat dies,

define ProductGuid = "{nnnnnnnn-nnnn-nnnn-nnnn-nnnnnnnnnnnn}"

Daher aktualisieren wir die Produktguid (nicht die Produkt -Upgrade -Richtlinie) für jede Version.

Das Mittel bestand darin, das Build -Skript dieser DLL leicht zu ändern, um die Montageversion auf '10 .0 zu setzen.1. {Git rev-list-Count Head} ', vermutlich als höher nummerierte Version behandelt.

Warum das funktioniert hat, kann ich nicht erklären.