8 replies to this topic

[ali]

Hallo,
da wir mit dem Major Upgrade probleme haben, und diverse Files nicht ersetzt werden wenn eine Anwendung noch geöffnet ist, würde ich gerne so ziemlich am Anfang der installation überprüfen, ob bestimmte Prozesse auf dem System noch laufen. Gibt es hierfür eine Funktion in IS oder eine Tabelle wo man die Prozesse eintragen kann die überprüft werden sollen?
danke
ali

[ali]

also, ich habe das jetzt mal so wie Microsoft das vorschlägt gemacht, und die RemoveExistingProducts Action ans Ende der Installationssequenz gestellt. Nun wird erst installaiert und dann entfernt. Wie es der Teufel aber will, kommen hier reihenweise andere Probleme, zb. das CustomActions erst nach der Installation des neuen Produktes in Deinstall des alten Produktes ausgeführt werden. Dies hat zur Folge, das Teilweise Informationen mit der Installation geschrieben, und dann beim Deinstallieren des alten Produktes direkt wieder von eine Custom Action aus dem alten Produkt gelöscht werden.
Ich habe nun versucht eine Bedingung zu setzen, so dass die CA's beim Entfernen nicht ausgeführt werden, wenn das alte Produkt von einem Major Upgrade entfernt wird. Die Property IS_MAJOR_UPGRADE wird aber sinnigerweise nicht an den Deinstall des alten Produktes weiter gegeben, so das diese beim Entfernen nicht ausgewertet/berücksichtigt wird.

Wie kann ich im alten Produkt erkennen, ob dessen Remove von einem Major Upgrade durchgeführt wird, oder durch Systemsteuerung/Software im OS?

[ali]

ok, die Antwort heißt wohl "UPGRADINGPRODUCTCODE", nur leider habe ich dies nicht in der Bedingung der CA im vorherigen Produkt als Bedingung mit aufgenommen so das diese auch beim Upgrade ausgeführt werden.

[Stefan Krueger]

Normalerweise werden Dateien, die von einem Proess verwendet werden, bei InstallValidate erkannt und dann der FileInUse Dialog angezeigt.

[ali]

Das Problem mit den gesperrten Files ist, dass der Installer zwar ausgibt das die Anwendung im Zugrif ist, aber nach dem Beenden der Anwendung die das File geöffnet hat, das File nicht als ACTION:local deklariert. Ich denke das es daran liegt, weil der Installer bei der vorhergehenden Aktion "CostFinalize" die gesperrten Files so ausgibt:
Disallowing installation of component: {F6C38648-0DB9-4CA1-B133-169B9D029CA5} since the same component with higher versioned keyfile exists
Bei dieser Komponente handelt es sich um eine mdb die im Zugriff ist. Dieses Ergebnis erhalte ich immer wenn eine mdb beim Install geöffnet ist, das kann ich auf unseren Testsystemen reproduzieren. Das Resultat ist, das nach dem Major Upgrade die mdb nicht mehr auf dem System vorhanden ist, da diese beim Remove des alten Produktes entfernt wird.

Edited by ali, 22 April 2008 - 11:16.

[Stefan Krueger]

Ich denke, das würde auch passieren, wenn die mdb nicht geöffnet ist. Welches Verhalten ist denn gewünscht: soll die vorhandene Datenbank beibehalten werden oder soll sie überschrieben werden?

[ali]

die Datenbank soll ersetzt werden, und nein, das passiert nicht wenn die Datenbank geschlossen ist. Wir haben derzeit ein paar Supportfälle, wo wir nachvollziehen können das die Datenbank nach der Installation nicht mehr da ist, wenn und auch nur dann wenn die Anwendung beim Update geöffnet war und über die IS Dialog "FilesInUse" geschlossen wird. Das sieht man im Log, und ich kann es auch 1:1 nachvollziehen auf unseren Testsystemen.

Edited by ali, 23 April 2008 - 11:15.

[Stefan Krueger]

Hast recht, das würde nur passieren, wenn die mdb als "never overwrite" markiert wäre.

In den Major Upgrade Settings kann man angeben, welche Features der alten Version entfernt werden sollen. Normalerweise steht da nichts drin, d.h. alle werden entfernt. Du könntest versuchen, dort alle Fetaures einzutragen außer dem mit der mdb.

Ein weiterer Ansatz wäre, die Komponente auf "always overwrite" zu stellen. Das ist aber gefährlich, denn sie könnte dann auch zwischendurch bei einem Repair überschrieben werden.

Oder du versuchst das frühzeitig (am besten vor dem Costing) abzufangen. Es gibt ein InstallScript "List and Shut Down Running Applications" unter http://www.installsi.../en/isp_ext.htm das dir vielleicht dabei hilft.

[ali]

das mit dem Feature ausschließen wird nicht gehen, da in diesem noch andere Komponenten drinne hängen, die auch ersetzt werden müssen.

bei "always overwrite" bin ich skeptisch, da zum einen wie du sagst das Problem mit dem Reparieren besteht, zum anderen weiß ich nicht, ob dann überhaupt noch ein späteres Patch machbar ist.

Eine Script Funktion die auf gesperrte Dateien prüft, habe ich schon für die Netzwerkinstallation, da setze ich ein script ein, um zu prüfen, ob ein anderer Client die zu aktualisierenden Komponenten am Netzwerkspeicherort noch im Zugriff hat. So eine Funktion bietet IS ja nur für den lokalen Client auf dem das Setup läuft.
Ich denke ich werde dieses Script auch bei dem jetzigen Problem verwenden können.

Danke.
ali

Edited by ali, 29 April 2008 - 13:19.