Beeinflussen d. DeInstallationsreihenfolge beim MajorUpgrade

Melchior Joined: 29 May 2006 Posts: 29

Beeinflussen der Sortierreihenfolge für die DeInstallation fremder Produktfamilien beim MajorUpgrade

Bei Windows Installer Setups wird innerhalb des MajorUpgrades mittels der Action RemoveExistingProducts eine DeInstallation allfälliger Vorprodukte initiiert. Die DeInstallation erfolgt dabei während des Installationsprozesses als eingebettete Installation innerhalb der gleichen Installationsinstanz.
Um eine DeInstallation auszulösen muss der entsprechende UpgradeCode in der Upgrade Tabelle eingetragen sein und diesem eine Property über ActionProperty zugewiesen werden, welche über SecureCustomProperties als Public Property bekannt gemacht wurde. Die meisten Authoringtools verfügen über einfache Verfahren, diesen Upgrade zu implementieren.
Schwieriger wird es, wenn man eine bestimmte DeInstallationsreihenfolge vorgeben möchte, vor allem wenn es sich um produktlinienfremde Applikationen handelt, die vor der eigenen Produktlinie entfernt werden sollen. Denn Windows Installer ermittelt die zu deinstallierenden Produkte über die Action FindRelatedProducts und sortiert die ermittelten ProductCodes nach eigenem Schlüssel. Die Sortierung setzt sich folgendermassen zusammen:

Als erstes werden alle ProductCodes gesucht, welche den eigenen UpgradeCode verwenden (welcher als UpgradeCode in der Property Tabelle definiert ist). Man kann diese Sortierung auch beobachten, indem man in der Upgrade Tabelle nach dem Eintrag einiger GUIDs als letzte Operation den eigenen UpgradeCode hinzufügt. Nach dem Speichern und Wiederöffnen der MSI befindet sich der eigene UpgradeCode an erster Stelle.
Nach Records in der Upgrade Tabelle sequenziell orientierte Sortierung (Reihenfolge der UpgradeCodes innerhalb der Upgrade Tabelle).
Werden für einen in der Upgrade Tabelle gelesenen Record mehrere gültig installierte Produkte vorgefunden, so werden diese nach der auf diesem Client erfolgten Installationsreihenfolge sortiert.

Eine anschliessende DeInstallation über RemoveExistingProducts erfolgt daher nicht immer in der gewünschten Abfolge. Auch die Verwendung unterschiedlicher und alphabetisch benannter ActionProperties verhilft uns in solchen Fällen zu keinem erfolgreichen Ergebnis. Möchte man einer bestimmten, durch einen eindeutigen UpgradeCode definierten und fremden Produktfamilie, unabhängig der Windows Installer Sortierreihenfolge, den zeitlichen Vorrang geben, so dass diese vor der eigenen UpgradeCode-Gruppe deinstalliert wird, so gibt es verschiedene Lösungsansätze, wovon hier einer aufgezeigt werden soll:

Die Upgrade Tabelle mit den zu deinstallierenden UpgradeCodes abfüllen und für dieses Produkt, welches als erstes deinstalliert werden soll eine eigene ActionProperty verwenden.

Code:

UpgradeCode ActionProperty
{C84868AB-F3AC-11D4-882B-0050DAD07965}    REMOVEALLPRODUCTS
{E85AD41E-2144-4DB9-A149-951B29E7AAAD}    REMOVEALLPRODUCTS
{C106E40E-7E43-413D-B921-DF3FB646F781}    REMOVEALLPRODUCTS
{AC105C58-10DD-4AD7-8F94-00F71400C489}    FIRSTREMOVE
{421A321C-2214-4713-B3EB-253F2FBCCE49}    REMOVEALLPRODUCTS

Die verwendeten ActionProperties mittels SecureCustomProperties als Public Properties bekannt machen (Property Tabelle):

Code:

Property Value
SecureCustomProperties REMOVEALLPRODUCTS;FIRSTREMOVE

Zwei Type 51 CustomActions in der CustomAction Tabelle eintragen, welche die ActionProperties neu ordnen sollen. Type 51 CustomActions weisen Properties einen bestimmten Wert zu.

Code:

Action Type Source Target
SetNewREMOVEALLPRODUCTS 51 REMOVEALLPRODUCTS [FIRSTREMOVE];[REMOVEALLPRODUCTS]
ClearFIRSTREMOVE 51 FIRSTREMOVE

Die zwei CustomActions in der InstallExecuteSequence Tabelle nach FindRelatedProducts und vor RemoveExistingProducts eintragen und sie so konditionieren, dass diese nur beim Vorfinden der FIRSTREMOVE-Applikation ausgeführt werden:

Code:

Action Condition Sequence
(FindRelatedProducts 410)
SetNewREMOVEALLPRODUCTS FIRSTREMOVE 420
ClearFIRSTREMOVE FIRSTREMOVE 430

Nun wird die ActionProperty REMOVEALLPRODUCTS so zusammengesetzt, dass der oder die ProductCode/s der mit FIRSTREMOVE deklarierten Produktfamilie am Anfang steht und auch die DeInstallation dieser Produktfamilie erfolgt nun während dem MajorUpgrade als erstes. Dieses Verfahren funktioniert auch, wenn nur das Produkt FIRSTREMOVE gefunden wurde und REMOVEALLPRODUCTS in diesem Fall mit {GUID}; und Semikolon beendet wird.

Dominik Oberlin