10 replies to this topic

[Holger_G]

Hallo,

damit eine Custom Action während der Deinstallation der 'alten' Installation bei einem Major Upgrade nicht ausgeführt werden soll, kann man ja die NOT UPGRADINGPRODUCTCODE Kondition verwenden.
Dummerweise wurde diese Kondition in der 'alten' Installation aber nicht gesetzt und nun wird die Custom Action auch bei einem Major Upgrade ausgeführt. Kann man das ggf. irgendwie umgehen? Ich habe bislang nur eine Möglichkeit in Form einer VBScript CA gefunden, mit der man die lokale MSI Kopie modifiziert. Die Lösung finde ich aber nicht so gut. Ansonsten könnte man ja noch ein Minor Upgrade dazwischen 'schieben', mit dem die Kondition geupdated wird.
Gibt es evtl. noch einen anderen Trick?

Edited by Holger_G, 19 April 2010 - 10:48.

[Stefan Krueger]

Wenn für die Action keine Bedingung gestezt ist (also auch keine andere die man irgendwie tricksen könnte) dann wäre ein zwischengesschaltetes Minor Update wohl das beste.

[Holger_G]

Folgende Bedingung ist gesetzt:
(DATABASE=OriginalDatabase) AND (REMOVE="ALL")

Aber da kann man nicht viel tricksen, oder?

[Stefan Krueger]

DATABASE ist doch dein eigenes Property, oder? Das könntest du vielleicht auf einen Dummy-Wert setzen.
Außerdem könntest du in der Upgrade Tabelle angeben, welche Features der alten Version entfernt werden sollen. Default ist leer, was bedeutet "alle". Wenn du dort aber alle Features bis auuf eines aufzählst, dann bleibt dieses eine Feature zurück, und REMOVE=Feature1,Feature2,usw. und eben nicht "ALL". Hat aber den Nebeneffekt, dass die alte Version eben nie komplett entfernt wird.

[Holger_G]

Das Setup beinhaltet lediglich ein Feature, also kommt das leider nicht in Frage.
DATABASE ist keine eigene Property, ich habe das mal in einem älteren InstallShield Artikel gelesen -> Q105766: INFO: Detecting If a Setup Is Launched from Add/Remove Programs.

[Stefan Krueger]

Ja, dann scheidet das wohl aus.

[ali]

Hallo,
selbiges Problem hatte ich auch schon einmal vor ca. einem Jahr. Ich habe als Lösung ein Patch gebaut, der die Bedingung in der alten gecachten MSI anpasst. Das Patch habe ich (tu ich immer noch) in der UI Sequenz des neuen Setup ausgeführt. Als Ausführungsbedingung verwende ich den ProductCode des alten Setup mit der Property aus der Upgradetabelle.

[Holger_G]

[Holger_G]

@ali:

ali, ich würde deine vorgeschlagene Lösung gern mal ausprobieren. Kannst du mir ggf. ein paar mehr Details geben? Ist der Patch Bestandteil des InstallShield Projekts (bspw. in den Support Files) oder wie machst du das? Wo in der UI Sequence startest du den Patch mit welchen Commandline Parametern? Das mit dem ProductCode des alten Setups und der Bedingung ist mir auch nicht ganz klar.

[ali]

- Die msp Datei liegt in den SupportFiles unter Language Independent.
- Ausführen mittels CA mit der Einstellung:
Working Directory: SystemFolder
Filename & CommandLine : msiexec.exe /p [SUPPORTDIR]\MyPatch.msp /qn
ReturnProzessing: Synchronous
Inscripr-Execution : Immediate Execution
Install UI Sequenz : AfterSetupProgress
InstallUICondition : REMOVEPRODUCT = "{ProductCode}" AND NOT NOPATCH

Das Property "REMOVEPRODUCT" wird durch den Eintrag unter Media/Upgrades -> "Detect Property" gefüllt. Es ist das Property, das erkennt, das ein Produkt installiert ist und ein z.B. MajorUpgrade initiiert. Wenn die Sequenz "FindRelatedProducts" das unter Upgrades eingetragene Produkt auf dem Zielsystem findet, wird der "ProductCode" in diesem Property gespeichert. Daher kann man das Property inkl. ProductCode als Bedingung verwenden.

Die Property NOPATCH habe ich eingefügt, um in einem Supportfall eine Möglichkeit zu haben, durch das setzen der Propery die Ausführung des Patches zu verhindern.

Edited by ali, 27 April 2010 - 08:40.

[Holger_G]

Besten Dank! Die Lösung gefällt mir besser als meine Prerequisite Lösung.