17 replies to this topic

[ali]

Hallo,

bei einem heutigen Supportfall hat mich der CostFinalize so ziemlich angenervt.
Wir bieten beim Installieren die Möglichkeit die DBs auch zentral abzulegen, dies hat der Kunde auch in den Pfad "\\Server\Freigabe\MDB" getan. Nun ist ihm der Server abgeraucht und er wollte unser Programm neu in ein lokales Verzeichnis installieren. Beim Uninstall kommt jedoch beim CostFinalize die Meldung das \\Server\Freigabe\MDB nicht gefunden werden kann. Das Verzeichnis wird während des CostFinalize wohl irgendwo aus der Registry gezogen und versucht dem ursprünglichen Verzeichnisproperty [MDB] zuzuordnen. Beim Prüfen wird festgestellt das das Verzeichnis nicht erreichbar ist und die Installation bricht ab. Versuche das Property von außen mitzugeben sind gescheitert. Ich habe auch versucht in die temporäre MSI eine CA über Orca einzubauen die das Property auf einen andern Wert setzt, nichts geht. Wie soll ich da ran kommen. Wie/Wo muss ich meine Installation anpassen, damit mir das in Zukunft nicht mehr passiert und ich auch bei einem Deinstall diesen Verzeichnispfad nachträglich noch umsetzen kann?

[Stefan Krueger]

Du bist sicher, dass du das richtige Verzeichnis-Property setzt? Ist es ein public Property, also Name nur in Großbuchstaben? Ist es im Property SecureCustomProperties aufgeführt? Dann sollte es von der Kommandozeile aus setzbar sein.

Wenn du die .msi Datei anpasst und z.B. eine Custom Action Typ 51 vor InstallInitialize einbaust, dann musst du diese .msi per msiexec.exe mit Parameter REINSTALLMODE=v aufrufen, damit auch wirklich die neue .msi Datei verwendet wird. Der PackageCode muss natürlich auch geändert werden. Im Log solltest du dann sehen, ob deine CA ausgeführt wird.

[ali]

Hallo,
das Setzen der Property war ohnehin nur ein Test. Nach meinen jetzigen Versuchen mit dem Problem macht es m.E. eh wenig Sinn das Property vorher zu setzen, da es beim Deinstall im CostFinalize wieder auf den Ursprung der Installation gesetzt wird, auch wenn es schon korrekt gesetzt war:
PROPERTY CHANGE: Modifying MDB property. Its current value is '\\Server\Freigabe\MDB'. Its new value: '\\Server\Freigabe\MDB'.

Nö, meiner Meinung nach ist an der Ecke was vom MSI falsch. Wenn ich eine Installation erstelle und Daten in einen UNC-Pfad ablege und dann wieder Deinstalliere, dann habe ich folgendes Verhalten:

Zielpfad der Daten:
\\Server\Freigabe\MDB

-Wenn ich die Freigabe wegnehme, dann bekomme ich beim CostFinalize der Deinstallation die oben genannte Meldung, das auf den Pfad nicht zugegriffen werden kann und die Deinstallation bricht ab.

-Bennen ich aber nur das Zielverzeichnis im UNC-Pfad für die Deinstallation um also zb. in:
\\Server\Freigabe\__MDB
dann läuft die Deinstallation durch. Der CostFinalize setzt die Ursprünglichen Pfade auf \\Server\Freigabe\MDB, obwohl dieser Pfad nicht erreichbar ist, da der Zielpfad ja umbenannt wurde.

Also Zielfreigabe entfernen = Fehler/Abbruch, Zielverzeichnis umbenennen = kein Problem.
Ist doch irgendwie nicht ganz normal oder?

[Stefan Krueger]

Könnte mit der Speicherplatzberechnung zusammenhängen. CostFinalize will prüfen, ob genug Platz da ist (auch wenn das bei der Deinstallation vielleicht nicht unbedingt nötig ist). Dazu muss es prüfen, wieviel Platz auf dem Zeillaufwerk vorhanden ist. Und dazu muss der Server erreichbar sein.

[ali]

ja, das denke ich auch. Aber wieso funktioniert die Deinstallation wenn ich das Zielverzeichnis umbenenne, in diesem Fall ist das Zielverzeichnis doch auch nicht erreichbar und es kann keine Berechnung stattfinden und es können auch keine Komponenten entfernt werden?!

[Stefan Krueger]

Doch. So lange das Laufwerk erreichbar ist, kann Windows Installer den *verfügbaren* Speicherplatz abfragen. Das ist ja unabhängig vom Verzeichnis.

[ali]

Wenn das so ist, aber wieso. Der Speicherplatz auf einem Netzlaufwerk ist doch unerheblich für die Deinstallation. Es wird doch höchsten lokaler Platz verwendet. Wenn eine Prüfung nur auf vorhandenen Speicherplatz durchgeführt wird, ist das doch ein generelles Problem für die Deinstallation. Ich kann doch als Windows Installer nicht grundsätzlich davon ausgehen, das bei der Deinstallation der identische UNC Zielpfad vorhanden ist wie bei der Installation. Es muss doch zumindest die Möglichgkeit geben diesen zu korrigieren bzw. diese Prüfung zu überspringen. Wie mache ich das?
Wir bekommen solche Installationen nur vom System in dem wir manuell in der Registry austragen, was extrem unsauber ist.

Edited by ali, 02 January 2012 - 14:31.

[Stefan Krueger]

Kannst du bitte mal ein Stük aus der Logdatei posten, mit CostFinalize und der Fehlermeldung, die zum Abbruch führt? Eigentlich hätte ich gedacht, dass Windows Installer den Pfad zurück auf den Defaultwert setzt, wenn das Ziel nicht erreichbar ist.

[ali]

MSI (s) (BC:98) [15:57:03:720]: Doing action: CostFinalize
Aktion beendet um 15:57:03: IsolateComponents. Rückgabewert 0.
MSI (s) (BC:98) [15:57:03:720]: PROPERTY CHANGE: Adding OutOfDiskSpace property. Its value is '0'.
MSI (s) (BC:98) [15:57:03:720]: PROPERTY CHANGE: Adding OutOfNoRbDiskSpace property. Its value is '0'.
MSI (s) (BC:98) [15:57:03:720]: PROPERTY CHANGE: Adding PrimaryVolumeSpaceAvailable property. Its value is '0'.
MSI (s) (BC:98) [15:57:03:720]: PROPERTY CHANGE: Adding PrimaryVolumeSpaceRequired property. Its value is '0'.
MSI (s) (BC:98) [15:57:03:720]: PROPERTY CHANGE: Adding PrimaryVolumeSpaceRemaining property. Its value is '0'.
MSI (s) (BC:98) [15:57:03:720]: PROPERTY CHANGE: Modifying SystemFolder property. Its current value is 'C:\Windows\SysWOW64\'. Its new value: 'C:\Windows\SysWOW64'.
...

MSI (s) (BC:98) [15:57:03:814]: Note: 1: 1314 2: \\TESTSRV01\Freigabe\Server\program files\alv\Easy\
MSI (s) (BC:98) [15:57:03:814]: Note: 1: 1606 2: \\TESTSRV01\Freigabe\Server\program files\alv\Easy\
Aktion gestartet um 15:57:03: CostFinalize.
MSI (s) (BC:AC) [15:58:24:564]: I/O on thread 2012 could not be cancelled. Error: 1168
MSI (s) (BC:AC) [15:58:24:564]: I/O on thread 2108 could not be cancelled. Error: 1168
MSI (s) (BC:AC) [15:58:24:564]: I/O on thread 2912 could not be cancelled. Error: 1168
MSI (s) (BC:AC) [15:58:24:564]: I/O on thread 3144 could not be cancelled. Error: 1168
MSI (s) (BC:AC) [15:58:24:564]: I/O on thread 2096 could not be cancelled. Error: 1168
MSI (s) (BC:AC) [15:58:24:564]: I/O on thread 3504 could not be cancelled. Error: 1168
MSI (s) (BC:AC) [15:58:24:564]: I/O on thread 1996 could not be cancelled. Error: 1168
MSI (s) (BC:AC) [15:58:24:564]: I/O on thread 3656 could not be cancelled. Error: 1168
MSI (s) (BC:AC) [15:58:24:564]: I/O on thread 3724 could not be cancelled. Error: 1168
MSI (s) (BC:AC) [15:58:24:564]: I/O on thread 3032 could not be cancelled. Error: 1168
MSI (s) (BC:AC) [15:58:24:564]: I/O on thread 3356 could not be cancelled. Error: 1168
MSI (s) (BC:AC) [15:58:24:564]: I/O on thread 1636 could not be cancelled. Error: 1168
MSI (s) (BC:AC) [15:58:24:564]: I/O on thread 3480 could not be cancelled. Error: 1168
MSI (s) (BC:AC) [15:58:24:564]: I/O on thread 3808 could not be cancelled. Error: 1168
MSI (s) (BC:AC) [15:58:24:564]: I/O on thread 3232 could not be cancelled. Error: 1168
MSI (s) (BC:AC) [15:58:24:564]: I/O on thread 3976 could not be cancelled. Error: 1168
MSI (s) (BC:98) [15:58:24:564]: Produkt: TestInstallation -- Fehler 1606. Zugriff auf die Netzwerkadresse \\TESTSRV01\Freigabe\Server\program files\alv\Easy\ war nicht möglich.

MSI (s) (BC:98) [15:58:24:564]: Note: 1: 1606 2: \\TESTSRV01\Freigabe\Server\program files\alv\Easy\
MSI © (98:A4) [15:57:03:814]: Font created. Charset: Req=0, Ret=0, Font: Req=MS Shell Dlg, Ret=MS Shell Dlg

Fehler 1606. Zugriff auf die Netzwerkadresse \\TESTSRV01\Freigabe\Server\program files\alv\Easy\ war nicht möglich.
MSI (s) (BC:98) [15:58:31:845]: Produkt: TestInstallation -- Fehler 1606. Zugriff auf die Netzwerkadresse \\TESTSRV01\Freigabe\Server\program files\alv\Easy\ war nicht möglich.

MSI © (98:A4) [15:58:24:564]: Font created. Charset: Req=0, Ret=0, Font: Req=MS Shell Dlg, Ret=MS Shell Dlg

Fehler 1606. Zugriff auf die Netzwerkadresse \\TESTSRV01\Freigabe\Server\program files\alv\Easy\ war nicht möglich.
Aktion beendet um 15:58:31: CostFinalize. Rückgabewert 3.
Aktion beendet um 15:58:31: INSTALL. Rückgabewert 3.

[Stefan Krueger]

Ich nehme an, das gleiche passiert auch, wenn du msiexec.exe /x {[ProductCode]} startest?

[ali]

Ja, genau, da tritt die gleiche Fehlersituation auf.

[Stefan Krueger]

Mist...

Dann fällt mir leider momentan auch keine Lösung ein.

[ali]

hm, ist das nicht ein Fehlverhalten vom Installer? Kann man das Microsoft irgendwie vermitteln?

[Stefan Krueger]

Du kannst dafür einen Support-Case bei Microsoft aufmachen. Allerdings bin ich nicht sicher, ob sie es als Bug anerkennen. Ich glaube nciht, dass irgendwo dokumentiert ist, wie sich Windows Installer verhalten soll, wenn es das Laufwerk plötzlich nciht mehr gibt. In gewisser Weise ist das Verhalten sogar sinnvoll: Wenn der UNC-Pfad fehlt, weil du vergessen hast, dich beim Server einzuloggen würden sonst Trümmer zurückbleiben. So bricht das Setup ab und du hast die Möglichkeit, die Server-Verbindung herzustellen um dann eine saubere Deinstalaltion zu machen.

[ali]

ich gebe dir schon in soweit recht, dass es hier Trümmer zurückbleiben, wenn die Installation den UNC-Pfad nicht findet. Aber das Verhalten, dass dieses Problem nicht lösbar ist, wenn der Server nicht mehr da ist, weil sich der Pfad bzw. der Servername ändert ist schlichtweg ein Hammer. Es kann doch nicht sein, dass ich beim Kunden manuell in der Regsitry rumfuscheln muss, nur weil dem der Server abgeraucht ist. Da müsste es schon einen Schalter geben, das dem Entwickler oder auch dem Kunden die Möglichkeit gibt, der Installation mitzugeben, in wie weit nicht lokale Speicherorte während des Setups behandelt werden. Zumindest müsste beim nicht erreichen des Serverpfades ein Dialog erscheinen, in dem der Kunde einen neuen Zielpfad auswählen, bzw. diesen korrigieren kann.

[Majue]

Wenn ein Programm gestartet wird, bei dem Teile auf einem nicht verfügbaren Laufwerk im Netz liegen, startet automatisch der Installer und stellt diese im lokalen Standardpfad wieder her. Anschließend kann das Programm dann auch ordnungsgemäß deinstalliert werden. So war es jedenfalls bei meinem Setup.

Vielleicht hilft es, wenn vor der Deinstallation einmal "Reparieren" ausgeführt wird?

[Stefan Krueger]

Ja, da stimme ich dir zu.
Als ALternative zum manuellen Eingriff in die Registry gibt es seit kurzem ein offizielles Tool von Microsoft:
http://msmvps.com/bl...creenshots.aspx

[ali]

ich habe mich mit dem Problem jetzt noch ausführlicher beschäftigt.
Das Problem hat man ausschließlich wenn der Pfad ein UNC Pfad ist, also mit einem \\Servername beginnt. Nutzt man anstelle diesem ein Netzlaufwerk zb z:\Ordner dann kommt diese Problem nicht vor, in diesem Fall werden im CostFinalize lokale Ordner ausgehend vom RootProperty gezogen.
Weiter ist mir aufgefallen, das man das Problem nur mit Subdirectories ausgehen vom Rootdirectory mit UNC Pfad hat. Ein Beispiel:

In der DirectoryTable gibt es die folgenden Einträge:
DATABASEDIR, TARGETDIR, Daten
MDB, DATABSEDIR, Mdb
DOC, DATABASEDIR, Doc

Wenn der Server beim Deinstall nicht erreichbar sein sollte, wird DATABASEDIR auf "C:\" gesetzt. Bei MDB und DOC wird allerdings versucht diese auf den bei der Installation mitgegebenen UNC Pfad zu setzen. Dadurch kommt es zum beschriebenen Fehler. Manuelles anpassen von MDB und DOC über CommandLine oder CA schlägt auch fehl, die Properties werden im CostFinalize trotzdem versucht umzusetzen.
Ein ganz anderes verhalten, wenn ich anstelle des UNC-Pfades einen Netzlaufwerk (z:\) verbinde und mitgebe. Wenn ich hier bei der Deinstallation das Netzlaufwerk trenne und die Freigabe am Server wegnehme, dann werden die Properies wie folgt gesetzt:

DATABSEDIR, C:\
MDB, C:\Mdb
DOC, C:\Doc

somit gibt es bei der Deinstallation keine Probleme.
Ich kann mir nicht vorstellen, dass dieses unterschiedliche Verhalten wirklich gewollt ist.

Edited by ali, 13 January 2012 - 11:17.