DLLs werden nicht upgedated
Posted 19 December 2005 - 13:38
Posted 20 December 2005 - 09:01
Posted 21 December 2005 - 17:48
Posted 22 December 2005 - 10:06
Edited by ali, 22 December 2005 - 10:07.
Posted 22 December 2005 - 18:15
Und jetzt ist noch etwas neues aufgetaucht. In einem Versuchsprojekt Release 1 bzw. 2 benutzte ich ein Merge Modul 1 bzw. 2 und wollte darin 6 dlls updaten, mit folgenden Einstellungen im Merge Modul 1:
Extract COM Info: Ja, Self Register: Ja, Always Overwrite: Ja
(dies für alle dlls) und dies liess sich installieren ohne Fehler (auch unser Hauptprodukt mit diesem Merge Modul lief einwandfrei).
Merge Modul 2 (Reihenfolge wie oben):
Ja ja ja
ja nein ja
nein ja ja
Ja ja nein
ja nein nein
nein ja nein
Beim laufen lassen des Versuchsprojekts 2 mit diesem Mergemodul 2 kam am Anfang folgende Fehlermeldung:
Error 1606 Could not access network location DLL.
Ich weiss, dass Extract COM und Self Register eigentlich nicht beide gesetzt sein sollten, aber das Hauptprodukt lief ja. Ich fühle mich wirklich langsam verloren in diesem Wald von Geheimnissen. Z.B. muss man jedesmal ein neues Mergemodul (mit anderem Namen) machen, wenn auch nur das geringste ändert? Ich habe erneut das Phänomen, dass ich ein anderes Merge Modul gleichen Namens im Hauptprojekt gar nicht auswählen kann; es bleibt immer das alte drin. Auch muss doch irgendwo beschrieben sein, wie all die Settings einzustellen sind, usw.
Posted 23 December 2005 - 09:36
Er ersetzt ja nur neuere Versionen
Posted 23 December 2005 - 09:51
wenn du eine exe loggen willst musst du mit /V den Command übergeben
also
Setup.exe /V"/L*V c:\msi.log"
oder du schreibst im Projekt beim Menü Release unten bei MSI-Befehlszeilenargumente den Eintrag /L*V c:\msi.log" rein. Dann wird der eintrag in die setup.ini geschrieben und mit in die exe kompiliert.
Ja, da hst du recht, COM Extrction und self register sollte man nicht zusammen machen, was da passiert wenn man das tut kann ich dir nicht sagen habe ich nie getestet.
Zu deinem Problem mit den Mergemodulen, da musst du ein bisschen aufpassen. Wenn du eine neues MErgemodul mit geleiben namen erstellst und das alte Mergemodule File auf der Festplatte umbenennst (zum sichern), dann wird der Link im Projekt auf das Umbenannte MergeModul automatisch angepasst, d.h. du hast dann immer noch das alte drin. Dieses Phänomen lässt sich vermeiden wenn du das alte MergeModul in ein anderes Verzeichnis verschiebst.
Posted 13 January 2006 - 13:29
1. Ein Log habe ich jetzt machen können mit einem Eintrag in Setup.ini; das ist sehr gut.
2. Ich habe jetzt einen erneuten Updateversuch gemacht. Obwohl ich jetzt sogar mittels Custom Actions gewisse alte dlls deregistriere und lösche, bevor die neuen Versionen installiert werden, sind am Schluss (nach dem update) immer noch die alten dlls drauf. Ich verstehe einfach nicht wie so etwas möglich ist. Ich möchte jetzt einfach mal all die verborgenen Faktoren wissen, die das Verhalten beeinflussen können. Das sollte doch prinzipiell bekannt sein. Dass die Kombination von COM-Extraction und Self-Register für alles verantwortlich ist, kann ich nicht glauben, da das in Versuchsprojekten reibungslos geklappt hat (ich meine: das updaten auf neuere dlls). Ich muss diesen Fall berücksichtigen, da von früher her bereits einige Kunden solche Versionen erhalten hatten und wir auch dort in der Lage sein müssen, die dlls zu updaten.
Was sollte man nun aus dem Logfile herauszulesen können?
3. Bez. Mergemodulversionen habe ich mich vielleicht unklar ausgedrückt. Ich habe für jede Mergemodul-Version einen eigenen Verzeichnisbaum auf meinem Entwickler-PC (bzw. auf einem Server bei uns) mit den jeweils richtigen DLL-Versionen, dem IS-Projektfile und auch dem kompilierten .msm; letzteres hat immer denselben Namen. Wenn ich nun im Hauptsetupprojekt von einem Mergemodul auf eines in einem anderen Pfad, aber mit demselben Namen, wechsle (durch Browsen zum neuen Mergemodul), dann klappt das manchmal und manchmal wieder nicht. Es ist für mich total unsichtbar, welche Faktoren im Hintergrund nun hier wieder am Werk sind. Genau solche Dinge sollte man einfach wissen, damit man die Sachen kontrolliert bereinigen kann. Ich habe mich nun so beholfen, dass ich dem Mergemodul bei jeder Änderung einen neuen Namen gebe, so dass ich mehrere voneinander unabhängige Mergemodule habe; jedoch weiss ich immer noch nicht, ob das das offiziell propagierte Verfahren ist oder nicht. Wo findet man etwas darüber?
Edited by lingold, 13 January 2006 - 17:05.
Posted 19 January 2006 - 16:05
Sind die dlls als shared gekennzeichnet?
benutzt du für das Update einen bestimmten Reinstallmode?
Welche Guids hast du im Projekt geändert (Upgrade, Product,Paket)?
Hast du Einträge in der Upgrade Tabelle?
Edited by ali, 19 January 2006 - 16:05.
Posted 19 January 2006 - 17:41
2. Die Dlls habe ich alle als Shared gekennzeichnet (das müssen sie aus dem Grund, weil wir zwei Haupt-Applikationen haben, die dasselbe Merge modul verwenden).
3. Reinstallmode? Habe ich noch nie "berührt". Ich habe gesehen, dass im Property Manager eine Property ReinstallModeText mit dem Wert "omus" eingetragen ist. Das ist wohl nicht gleichzusetzen mit der Property REINSTALLMODE (obwohl für diese in der Dok derselbe Defaultwert angegeben ist (??)). Wenn REINSTALLMODE den Wert omus hätte, dann müssten eigentlich die DLLs upgedated werden, wenn ich das richtig verstanden habe. Es gibt aber im Property Manager weder REINSTALL noch REINSTALLMODE. Da müsste ich schon noch mehr darüber wissen.
4. Meine Upgrade-Tabelle ist leer.
Posted 19 January 2006 - 17:49
msiexec.exe /i deinprojekt.msi REINSTALLMODE=vomus REINSTALL=ALL
von der CmdLine aufgerufen?
Edited by ali, 19 January 2006 - 17:54.
Posted 20 January 2006 - 11:32
Cmdline=REINSTALLMODE=vomus REINSTALL=ALL /L*v C:\Programme\myPrg.log
Na ja, das /L bewirkt die Erstellung eines Logfiles, das zwar sehr gross ist, aber woraus ich trotzdem keine genügenden Informationen herauslesen kann, die Hinweise zur Lösung des Problems gäben.
Das Resultat des obigen ist wieder das gleiche wie schon bisher: Die DLLs werden nicht upgedated.
Ich dachte, ich wolle nun mal den PC neu starten, denn manchmal kann er ja erst beim Neustart gewisse Dinge fertiginstallieren. Auch das wars auch nicht; die DLLs waren auch danach noch auf dem alten Stand.
Edited by lingold, 20 January 2006 - 11:35.
Posted 20 January 2006 - 12:02
hast du es mal mit einem Minor Upgrade versucht, indem du den Paket Code änderst und die MSI VErsion an 2. Stelle erhöhst also zb. von 1.2.0 auf 1.3.0?
Hast du dir das log file mal genau bei den Komponenten codes angesehn, hier wird aufgelistet welche Komponente warum nicht upgedatet werden. Kopiere dir mal einen Komponentencode aus deinem Projekt und such im logfile danach.
>denn sonst meldet er nämlich, es gehe nicht, man müsse zuerst die ältere Version des Produkts deinstallieren.<
hm, das sollte eigentlich schon gehen, da ist evt. was falsch eingestellt. Evtl. mal im diesem fall das log File Prüfen, und schauen was er bei der Versionkontrolle der schon installierten msi loggt.
Edited by ali, 20 January 2006 - 12:54.
Posted 23 January 2006 - 15:09
"Windows Installer Verbose Log Analyzer" -> WiLogUtl.exe
vielleicht mal danach Googeln.
Posted 25 January 2006 - 14:08
2. Habe im Log nochmals gesucht, nicht nur nach Filename (A.dll), sondern nach dem Component guid wie man ihn im IS projectfile findet. Resultat: Dieser Guid erscheint überhaupt nicht im logfile! Und die Stellen mit dem Filenamen geben wie schon gesagt nichts aufschlussreiches, also keinerlei Aussagen, warum nicht upgedated wurde.
3. Habe noch einen anderen Versuch gemacht: Bei unseren zwei neusten Merge modules habe ich bei allen dlls das key file ausgeschaltet (wir haben pro dll eine separate component, und früher hatte ich immer das dll als key file gesetzt). In diesem Fall werden die dlls tatsächlich upgedatet! Aber wie gesagt, es müssen sowohl das alte wie auch das upzudatende merge module so eingestellt sein. Wenn das ältere Merge modul, das bei allen dlls das keyfile gesetzt hat (so wurde es an viele Kunden verschickt), verwendet wird, kann man sich beim neuen Merge modul noch so viel Mühe geben beim Key file ausschalten, es hilft alles nichts. Ab jetzt (=wirksam in der Zukunft) können wir natürlich schon so verfahren. Aber es scheint mir schon sehr bedenklich, wenn man zu so etwas Zuflucht nehmen muss, dass man ein Kernelement der MSI-Philosophie ausschalten muss, nur damit's geht. Allerdings: Mit Testprojekten ging es ja auch mit gesetztem Keyfile. Darum verstehe ich noch immer nichts.
Edited by lingold, 25 January 2006 - 14:20.
Posted 25 January 2006 - 14:41
Posted 25 January 2006 - 17:26
QUOTE |
Und die Stellen mit dem Filenamen geben wie schon gesagt nichts aufschlussreiches, also keinerlei Aussagen, warum nicht upgedated wurde. |
Was steht denn nun drin? Wenn du die Logdatei mit /L*v erstellt hast muss drin stehen ob die Datei schon vorhanden war order nicht und in welcher Version und ob er sie überschreibt oder nicht. Wenn die Datei überhaupt nicht im Log auftaucht dann ist irgendwas ganz verkehrt.
Stefan Krüger
InstallSite.org twitter facebook
Posted 26 January 2006 - 09:29
QUOTE |
Was steht denn nun drin? Wenn du die Logdatei mit /L*v erstellt hast muss drin stehen ob die Datei schon vorhanden war order nicht und in welcher Version und ob er sie überschreibt oder nicht. Wenn die Datei überhaupt nicht im Log auftaucht dann ist irgendwas ganz verkehrt. |
Ich kann leider nicht das ganze Logfile senden, da es über 500 KB ist und hier nur 100k Dateien gesendet werden können. Ich habe daher hier von 2 dlls (ctDocument.dll und ctDocument3.dll), die hätten upgedated werden sollen, alles hinzugefügt was ich im Logfile fand (indem ich einfach die strings "ctDocument.dll" bzw. "ctDocument3.dll" suchte):
----
MSI (s) (C8:A8): Component: ctDocument.dll.A31175DD_F3FD_42FF_9A6B_77090C72D9EC; Installed: Local; Request: Null; Action: Null
1: ctdocument.dll.A31175DD_F3FD_42FF_9A6B_77090C72D9EC
MSI (s) (C8:A8): Component: ctDocument3.dll.A31175DD_F3FD_42FF_9A6B_77090C72D9EC; Installed: Local; Request: Null; Action: Null
1: ctdocument3.dll.A31175DD_F3FD_42FF_9A6B_77090C72D9EC
---
Zu sagen ist, dass die Eigenschaft "key file" beim neuen Merge modul ausgeschaltet ist, während es beim alten eingeschaltet ist.
Ich sehe hier einfach nichts aufschlussreiches, oder sonst versteckt es sich irgendwo sonst im Logfile. Aber nach was muss ich denn suchen?
Posted 26 January 2006 - 09:32
Der Installer kann wohl keinen unterschied bzw. aktuellere Version feststellen.
Posted 26 January 2006 - 14:09
QUOTE |
hast du dir mal mit Orca die File Tabel der msi Tabelle angesehen und die Versionsnummern der Dlls der beiden Projekte alt/neu verglichen? |
QUOTE |
schrib doch mal welche Versionsnummer die alte VErsion der ctDocument.dll und die neu Version der ctDocument.dll hat. Der Installer kann wohl keinen unterschied bzw. aktuellere Version feststellen. |
Ich habe mir die neuste Version des Hauptprojekts (wo das merge modul eingebunden ist) im orca angesehen und Tabelle "File" geöffnet. Bei sämtlichen COM-dlls kommt da die Versionsnummer 65535.0.0.0. Das hat ja überhaupt nichts mit der Versionsnummer zu tun, die ich im File sehen kann, und die wäre für ctDocument.dll 1.2.0.125. Da verstehe ich schon wieder nur Bahnhof. Bei ocx-Files sieht die Sache wieder anders aus. Da scheinen die richtigen Versionsnummern drin zu stehen. Bei Microsoft-dlls ebenfalls, z.B. msjt4jlt.dll: 3.52.3328.0.
Posted 26 January 2006 - 14:52
Posted 26 January 2006 - 15:36
Posted 26 January 2006 - 15:48
Posted 26 January 2006 - 17:12
- Komponenten-Eigenschaftsseite
- Rechtsklick auf die Component
- Rechtsklick auf das File (dll)
Nirgends da finde ich "Systemversion außer kraft setzen", und die Versionsnummer auch nicht. Oder Tabelle "Component" im Direct Editor? Auch da nichts gefunden.
Posted 27 January 2006 - 08:23
Wenn du in deinem MergeModul Projekt, auf die bearbeitung der Komponeten klickst, dort eine Komponete auswählst in der deine DLL hängt und dort die eingebundene DLL mit rechtsklick anwählst, müsste ein Menü angezeigt werden wo du die Eigenschaften (oder Propertys) auswählen kannst. Dort müsste dies angezeigt werden, bei der Englischen Version natürlich entsprechend in Englisch.
Posted 27 January 2006 - 09:02
Posted 27 January 2006 - 09:12
Was passiert den wenn du diese Version mal bei einer Datei "nur zum testen" mal manuell in der File Tabel höher setzt also zb. auf 65535.1.0.0? Wird die Datei dann ersetzt?
Posted 27 January 2006 - 11:06
Posted 27 January 2006 - 11:21
- Die in Frage kommenden Merge modules (das alte und das neue) sind nicht im selben Verzeichnis. Ich kontrolliere auch immer den Pfad, der (wenn ein MM im Hauptprojekt selektiert ist) im rechten Bereich angegeben ist, so bin ich sicher dass das richtige gewählt ist.
Posted 27 January 2006 - 11:29
Posted 27 January 2006 - 11:54
Was wir (ein Kollege und ich) heute noch überlegt hatten, ist, dass man "künstlich" (d.h. mit Script und Custom Action) die dlls löscht, zu einem Zeitpunkt bevor der Standard file install geschieht, und zwar nicht im Setup, sondern von einem anderen Tool (eine Art "Starter" des Setups), das seinerseits das Setup aufruft. Denn wenn man dies im Setup selbst versucht, wird das dll einfach nicht gelöscht (andere Files wie mdb, txt, mit identischem Scriptaufruf, werden aber gelöscht). Wir wissen auch schon von früher, dass wenn man die dlls manuell löscht bevor das Setup aufgerufen wird, es dann klappt. Daher die Idee. Ein Test hat gezeigt, dass dies klappt, und solange sich keine andere Lösung zeigt, werden wir es wohl so machen müssen.
Posted 27 January 2006 - 12:36
Posted 27 January 2006 - 13:22
Trotz allem mal vielen Dank für deine Mühe.
Edited by lingold, 27 January 2006 - 13:23.
Posted 27 January 2006 - 18:26
QUOTE |
Zu sagen ist, dass die Eigenschaft "key file" beim neuen Merge modul ausgeschaltet ist, während es beim alten eingeschaltet ist. |
In diesem Fall musst du auch die ComonentId GUID ändern, und damit ist dann kein Minor Update mehr möglich, sondern nur noch ein Major Upgrade (ProductCode ändern).
Stefan Krüger
InstallSite.org twitter facebook
Posted 31 January 2006 - 10:24
Edited by lingold, 31 January 2006 - 10:30.
Posted 31 January 2006 - 10:36
Ich hatte mal das Problem, ich glaube es war das ATL MergeModule, wo ein Product Code im MergeModule gesetzt wurde. War ein Bug, dies führt dann dazu das die Product Codes in den fertigen MSI immer gleich sind und dann ist nix mit Updaten.
Posted 31 January 2006 - 11:11
1. Die drei ATL-Merge module, die ich in der Liste sehe (ATL 3.0 / 7.0 / 7.1) sind alle nicht gesetzt.
2. Ich habe bei VP1/2 mal alle Merge module gesetzt, die auch in unseren HP1/2 gesetzt sind, und das Updaten der dlls funktioniert jetzt immer noch.
Posted 31 January 2006 - 11:22
Wie gesagt ich habe nur vermutet das es die ATL war , ist schon länger her, aber das könnte das Problem sein.
Posted 31 January 2006 - 11:52
Du könntest mal die MSI Validierung laufen lassen, vielleicht siehst du da was, oder mit dem MSIDiff, wenn du das funktionierenden Msi mit dem nicht funktionierenden vergleichst!
Edited by ali, 31 January 2006 - 11:54.
Posted 31 January 2006 - 15:51
2. Ich weiss nicht ob es Sinn macht, all die fremden merge module zu untersuchen, denn der Test mit dem Versuchsprojekt hat ja gezeigt, dass all die anderen Merge Module offenbar nichts schlimmes bewirken.
3. Eine kleine Berichtigung: Ich bin der Meinung, dass man nicht sagen kann, das neue Projekt sei nicht funktionierend und das alte sei funktionierend. Denn wenn ich das neue auf einem PC installiere, wo nicht zuerst das alte installiert wurde, dann geht alles bestens, inkl. die dlls, die in ihren neusten Versionen erscheinen. Es sind eher beide gleich gut (oder gleich schlecht) funktionierend.
4. Ich habe mal eine MSI Validierung laufen gelassen. Weiss aber nicht so recht, was ich mit dem Resultat anfangen soll. Es gibt einige Errors und sehr viele Warnungen, aber bei beiden Kategorien tauchen nirgends die dll-Files auf, um die es geht.
Posted 01 February 2006 - 10:16
Stefan Krüger
InstallSite.org twitter facebook
Posted 01 February 2006 - 12:10
jsOffice.dll
ctCalculator3.dll
Die anderen 3 sich ändernden lauten:
ctCareCalculation.dll
ctDocument.dll
ctOfficeTemplate.dll
Und falls ein Vergleich mit nicht-ändernden dlls nützlich ist (nur 2 Beispiele):
jsDoubleCheck.dll
ctAccessControl2.dll
Im gemailten File sind 4 Logfiles, so dass gleich alles drin ist (alle zusammen gezippt sind leider grösser als 100KB). Auffällig ist die kleine Grösse des Logfiles HauptProjekt2.log, wenn man es vergleicht mit Versuchsprojekt2.log. Beim Versuchsprojekt sind alle sonstigen Mergemodule, die das Hauptprojekt hat, auch drin. Das Resultat beim Hauptprojektupdatingversuch war, dass dort die 2 manuell gelöschten dlls nach dem Update auf dem neusten Stand sind, die 3 andern nicht; beim Versuchsprojekt wurden alle 5 upgedatet.
Ich habe die 4 Logfiles in ein File gezippt und auf consulting@stefan-krueger.info gesendet.
Edited by lingold, 01 February 2006 - 12:24.
Posted 01 February 2006 - 12:56
CODE |
MSI (c) (F8:08): SELMGR: ComponentId '{F1E8FE82-4481-4BDA-8BF6-7146354D4DD6}' is registered to feature 'Programm', but is not present in the Component table. Removal of components from a feature is not supported! MSI (c) (F8:08): SELMGR: The feature-component mapping registration is broken for feature 'Programm' of product '{9A53DDF6-2602-41DA-B4CC-E3493322A410}' |
Das erklärt das Problem. Du hast offenbar eine Komponente vom Feature "Programm" gelöst. Das ist bei Small und Minor Updates nicht erlaubt. Schau mal nach, welche Komponente das ist mit ComponentId F1E8FE82-4481-4BDA-8BF6-7146354D4DD6 (könnte auch in einem Merge Modul sein)
Stefan Krüger
InstallSite.org twitter facebook
Posted 01 February 2006 - 13:38
Edited by lingold, 01 February 2006 - 14:39.
Posted 01 February 2006 - 14:44
Posted 02 February 2006 - 14:46
Stefan Krüger
InstallSite.org twitter facebook