Jump to content


This is a ready-only archive of the InstallSite Forum. You cannot post any new content here. / Dies ist ein Archiv des InstallSite Forums. Hier können keine neuen Beiträge veröffentlicht werden.
Photo

DLLs werden nicht upgedated


46 replies to this topic

lingold

lingold
  • Members
  • 42 posts

Posted 19 December 2005 - 13:38

In einem InstallShield 10.5 Premier, Basic MSI Projekt, habe ich ca. 20 DLLs in ein Merge Modul gepackt und dieses im Hauptsetup integriert. Nun gab es im Laufe der Zeit einen neuen Programm-Release, d.h. eine neue Version des Hauptsetups, und da haben auch gleich 5 dlls geändert (alles kleine, binärkompatible Änderungen). Wenn ich den Update laufen lasse, wird aber kein einziges DLL upgedated. Was mache ich falsch? Ich musste den Projektnamen des Mergemodules ändern, da es sich sonst nicht ersetzen liess (was mal das eine ist, das ich nicht begreife). Im Übrigen habe ich bei allen Files (dlls) die Eigenschaft "Always Overwrite" auf Ja gesetzt, aber das hilft nichts. Mag sein, dass die Namensänderung des Merge Moduls die Ursache ist. Ich sollte auch wissen wie das Versionsmanagement von Merge Moduls geht. Da gibt es einen Package Code und einen Module ID GUID, und eben den Namen des Merge Moduls (und ...?). Was muss man davon ändern und was nicht?

ali

ali
  • Full Members
  • 1,008 posts

Posted 20 December 2005 - 09:01

hast du mal ein log deines Updates erstellt, evtl hilft es auch einmal die fertig erstellt msi mit Orca zu öffnen um zu sehen ob die VErsionsnummern richtig eingetragen sind.

lingold

lingold
  • Members
  • 42 posts

Posted 21 December 2005 - 17:48

Meinst du ich soll das Build Log ansehen (das gewöhnlich immer erstellt wird)? Was ich mit Sicherheit sagen kann, ist, dass in der neuen Setup-Version (diejenige, die eben die ältere Software updaten soll) die richtigen, d.h. neueren dlls erscheinen, denn ich liess das Setup testhalber auf einem PC laufen wo nie eine ältere Version installiert wurde. Das Problem ist wirklich ein update-spezifisches Problem. Ich habe übrigens auch noch den Build Report (ein htm-File) gesehen, und dort sieht man anhand des Datums eines Files, dass es sich um die richtigen dlls handelt. Ich weiss also nach wie vor nicht, wie das ganze läuft und wie es zu lösen ist.

ali

ali
  • Full Members
  • 1,008 posts

Posted 22 December 2005 - 10:06

nein, ich meine das Schreiben eines Log files während du die Setup.exe ausführst und das Paket auf dem Zielsystem installierst. Dort musst du sehen wieso die Dlls nicht installiert werden.

Edited by ali, 22 December 2005 - 10:07.


lingold

lingold
  • Members
  • 42 posts

Posted 22 December 2005 - 18:15

Was ist die beste Art, ein Log zu schreiben? Muss ich mit MsiEnableLog arbeiten, oder mit dem Commandlineparameter /L (geht aber wohl nicht wenn das Setup in ein Setup.exe gepackt ist)?
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.




SomeOne

SomeOne
  • Members
  • 5 posts

Posted 23 December 2005 - 09:36

Setz einfach mal die Version der Dlls hoch.
Er ersetzt ja nur neuere Versionen

ali

ali
  • Full Members
  • 1,008 posts

Posted 23 December 2005 - 09:51

also mal zum log:
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.

lingold

lingold
  • Members
  • 42 posts

Posted 13 January 2006 - 13:29

Jetzt habe ich endlich wieder die Sache weiterverfolgt. Jetzt habe ich 3 Fragen/Bemerkungen.
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.


ali

ali
  • Full Members
  • 1,008 posts

Posted 19 January 2006 - 16:05

führst du ein minor oder ein Major Update durch?
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.


lingold

lingold
  • Members
  • 42 posts

Posted 19 January 2006 - 17:41

1. Ein major ist es nicht. Aber ob es minor oder small ist, ist mir nicht klar. Für den Update habe ich den Package Code geändert, nicht aber Upgrade und Product Code. Den dritten Zahlenblock der Product Version habe ich geändert, also z.B. von 1.2.167 auf 1.2.168. Demgemäss müsste es ein small upgrade sein.
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.

ali

ali
  • Full Members
  • 1,008 posts

Posted 19 January 2006 - 17:49

hm, hast du dein Update msi mal mit den Propertys

msiexec.exe /i deinprojekt.msi REINSTALLMODE=vomus REINSTALL=ALL

von der CmdLine aufgerufen?

Edited by ali, 19 January 2006 - 17:54.


lingold

lingold
  • Members
  • 42 posts

Posted 20 January 2006 - 11:32

Danke. Habe das gemacht, allerdings in anderer äusserer Form. Wie ich früher schon feststellen musste, kann man bei einem Update nicht das msi für den Aufruf benutzen, denn sonst meldet er nämlich, es gehe nicht, man müsse zuerst die ältere Version des Produkts deinstallieren. Man muss stattdessen das bei der nicht-gepackten Kompilierung mit-erzeugte Setup.exe benutzen, indem man es einfach doppelklickt. Die Commandline-Parameter kann man ins Spiel bringen, indem man sie ins Setup.ini hineinschreibt:

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.


ali

ali
  • Full Members
  • 1,008 posts

Posted 20 January 2006 - 12:02

ok, du machst ein small update,
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.


ali

ali
  • Full Members
  • 1,008 posts

Posted 23 January 2006 - 15:09

vielleicht hilft dir auch ein Tool von Microsoft zum lesen von logs:
"Windows Installer Verbose Log Analyzer" -> WiLogUtl.exe

vielleicht mal danach Googeln.

lingold

lingold
  • Members
  • 42 posts

Posted 25 January 2006 - 14:08

1. Habe jetzt einen Minor update versucht (bei mir war das von Version 8.2.xxx auf 8.3.yyy). Das hat auch nichts geholfen.
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.


ali

ali
  • Full Members
  • 1,008 posts

Posted 25 January 2006 - 14:41

hast du dir mal mit Orca die File Tabel der msi Tabelle angesehen und die Versionsnummern der Dlls der beiden Projekte alt/neu verglichen?

Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

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.

lingold

lingold
  • Members
  • 42 posts

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?


ali

ali
  • Full Members
  • 1,008 posts

Posted 26 January 2006 - 09:32

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.

lingold

lingold
  • Members
  • 42 posts

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.

ali

ali
  • Full Members
  • 1,008 posts

Posted 26 January 2006 - 14:52

jetzt schau mal bitte in deinem MergeModul Projekt, im Direkt Editor unter Files, ob dort die selben Versionsnummern drin stehen.

lingold

lingold
  • Members
  • 42 posts

Posted 26 January 2006 - 15:36

Merge Module: Da ist dieselbe Versionsnummer, nämlich 65535.0.0.0, drin, für alle unseren dlls.

ali

ali
  • Full Members
  • 1,008 posts

Posted 26 January 2006 - 15:48

wenn du jetzt in den komponenteneditor gehts, und dort unter da in der Komponente schaust wo eine dieser dlls drine hängt, dort unter dateien die Eigenschaften der eingebundenen dll anschaust. ist in dem Fensterchen evtl bei "Systemversion außer kraft setzen" ein häkchen gesetzt? und steht da die Version 65535.0.0.0 drin.

lingold

lingold
  • Members
  • 42 posts

Posted 26 January 2006 - 17:12

Was ist der Komponenteneditor? Meinst du in InstallShield? Ich finde nur:
- 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.

ali

ali
  • Full Members
  • 1,008 posts

Posted 27 January 2006 - 08:23

Als ich habe die deutsche Version von IS10.5 professional die wird sich denke ich in der Beziehung nicht so sehr von Premier unterscheiden.
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.

lingold

lingold
  • Members
  • 42 posts

Posted 27 January 2006 - 09:02

OK, wenn ich das mache, kommt eine Box mit dem Titel "Properties". Dort finde ich mehrere Checkboxen. Eine davon heisst "Override system version", diese hast du wohl gemeint. Sie ist disabled, aber wenn ich eine andere Checkbox namens "Always overwrite" unchecke (wir hatten sie nämlich immer eingeschaltet gehabt), wird sie enabled, und wenn ich sie dann checke (die "Override system version"), kann ich im untergeordneten Textfeld eine Version eingeben. In allen unseren Versionen des Merge moduls war dieses Textfeld immer leer (und disabled). Sollte jetzt ein geeigneter Eintrag in dieses Textfeld die Lösung bringen?

ali

ali
  • Full Members
  • 1,008 posts

Posted 27 January 2006 - 09:12

also ich habe bei mir mal geschaut, die VErsion 65535.0.0.0 wird wohl eingetragen, weil die Checkbox "Always overwrite" markiert ist. Ist diese Option beim vorhergehenden Mergemodul auch schon ausgewählt gewesen (mit selber Versionsnummer)?
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?

ali

ali
  • Full Members
  • 1,008 posts

Posted 27 January 2006 - 11:06

ich habe eben etwas in der InstallShield Hilfe gelesen. Dort steht, wen man 2 Merge Module mit dem selben Modul Guid in dem selben Soucre Pfad liegen hat und eins oder beide in sein Projekt einbindet, kann InstallShield nicht feststellen, welches Modul welches ist. Man darf also keine Module mit gleicher Merge_Module-Guid in einem Source Verzeichnis liegen haben. Hast du evtl dein altes und dein neues MergeModule in ein und dem selben Source Verzeichnis, dann könnte es sein das trotz das du dein neues beim einbinden angegeben hast doch das alte eingebunden wird. Bezeichnungen und MMVersionnen ändern da nichts.

lingold

lingold
  • Members
  • 42 posts

Posted 27 January 2006 - 11:21

- Manuelles Setzen auf 65535.1.0.0 hat auch nicht geholfen.
- 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.

ali

ali
  • Full Members
  • 1,008 posts

Posted 27 January 2006 - 11:29

bleibt mir eigentlich nur noch dir zu raten den Komponenten Guid zu Ändern für die entsprechenendn Komponenten, die Option always override würde ich hierfür zurück nehmen. Wenn das nicht hilft, weiß ich glaube ich auch nicht mehr weiter.

lingold

lingold
  • Members
  • 42 posts

Posted 27 January 2006 - 11:54

Nein, das mit dem Komponenten-Guid weiss ich zufällig; wenn man den ändert, geht es erst recht nicht (auch bei einem früheren Testprojekt probiert).
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.

ali

ali
  • Full Members
  • 1,008 posts

Posted 27 January 2006 - 12:36

wird wohl nix anderes übrig bleiben, es müsste aber auch über installscript im setup funktionieren, aber dann sehr früh in den sequenzen, bevor das ziel überprüft wird.

lingold

lingold
  • Members
  • 42 posts

Posted 27 January 2006 - 13:22

Ich machte es im Dialog SetupResume, im Event des Buttons Next (das ist im Fall des upgrades der letzte Dialog bevor der Installationsvorgang beginnt). Aber dort klappte es beim dll nicht, so wie vorher beschrieben.
Trotz allem mal vielen Dank für deine Mühe.

Edited by lingold, 27 January 2006 - 13:23.


Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 27 January 2006 - 18:26

Huch, ihr wart ja fleißig. Ich habe jetzt nicht alles gelesen, aber das ist mir ins Auge gesprungen:
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).

lingold

lingold
  • Members
  • 42 posts

Posted 31 January 2006 - 10:24

Ja, inzwischen habe ich weitere Versuche gemacht. Das Ausschalten der Eigenschaft "key file" war nur in diesem (und ganz wenigen anderen) Versuchen gemacht worden, lange nachdem wir unser dll-Problem zum ersten Mal beobachtet hatten. Ein Versuch, der sicherlich neue Aspekte zeigen könnte, ist mir jetzt gelungen: Ich habe zwei Versionen des merge moduls (MM1 und MM2) nochmals sauber kontrolliert und angepasst, so dass beide folgende Einstellungen haben: Shared, Always Overwrite, Self Register und Keyfile-Eigenschaft sind "ja" (aktiv), die anderen deaktiv. Dann habe ich vom Hauptprojekt die Versionen 1 und 2 (nennen wir sie mal HP1 und HP2) genommen und das entsprechende MM (MM1 bzw. MM2) eingebunden. Von HP1 auf HP2 habe ich nur den Package Code, nicht aber den Product Code geändert. Dann habe ich das (wie immer) in Virtual PC images getestet (wir müssen ja immer wieder einen "jungfräulichen" sauberen Originalzustand des Systems haben, das wäre sehr aufwendig mit einem "echten" PC). Dann habe ich HP1 installiert und HP2 darüber installiert. Resultat: Die DLLs wurden nicht upgedatet. Und jetzt das interessante: Ich habe ein kleines Versuchsprojekt in 2 Versionen erstellt, nennen wir sie VP1 und VP2. Auch dort habe ich nur den Package Code geändert von VP1 auf VP2. Und ich habe dieselben Merge module MM1 bzw. MM2 eingebunden. Das Resultat ist, dass es hier klappt mit dem Updaten der dlls!! Das muss darauf schliessen lassen, dass es nicht (oder nicht nur) an den Merge modulen liegt. Wir müssen damit wohl ziemlich andere Orte ins Auge fassen, um nach der Ursache zu suchen. Wir haben im HP1/2 ziemlich viele weitere Merge module (vor allem von Microsoft, z.B. alle von der Serie "Microsoft Windows Common Controls xx"), und ich habe da nie so genau untersucht ob wirklich alle nötig sind, nach dem Motto lieber zuviel als zuwenig. Könnte es sein, dass eine zu grosse Zahl von Merge modulen solche Nebeneffekte hervorruft? Oder wo müssen wir am ehesten suchen?

Edited by lingold, 31 January 2006 - 10:30.


ali

ali
  • Full Members
  • 1,008 posts

Posted 31 January 2006 - 10:36

was mir da einfällt, es gab da tatsächlich mal ein Problem mit Merge Modulen. Hast du mal den Product Code deines MSI Projektes mit dem der fertig erstellten MSI Datei verglichen, sind die gleich.
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.

lingold

lingold
  • Members
  • 42 posts

Posted 31 January 2006 - 11:11

Ich habe bereits wieder neue Nachrichten.
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.

ali

ali
  • Full Members
  • 1,008 posts

Posted 31 January 2006 - 11:22

hast du die Product Codes deines alten und deines neuen nicht funktionierenden msi mal verglichen?
Wie gesagt ich habe nur vermutet das es die ATL war , ist schon länger her, aber das könnte das Problem sein.

lingold

lingold
  • Members
  • 42 posts

Posted 31 January 2006 - 11:30

Ja, habe ich jetzt nochmals kontrolliert, sie sind gleich.

ali

ali
  • Full Members
  • 1,008 posts

Posted 31 January 2006 - 11:52

ach, da war ich ja auch auf dem falschen Dampfer, du machst ja nur ein Minor Upgrade, da bleibt der Product Code ja gleich. Hast du den Package Code mal überprüft, dieser müsstr ja nun unterschiedlich sein. Ist ne ziemliche fuddelarbeit so einen fehler zu finden, wenn er in einem fremden MergeModul stecken sollte.
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.


lingold

lingold
  • Members
  • 42 posts

Posted 31 January 2006 - 15:51

1. Package Code ist unterschiedlich (bei den msi). Bei den fraglichen Mergemodul-Versionen auch.
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.

Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 01 February 2006 - 10:16

Ich würde vorschlagen nochnal ein Log zu schreiben, mit dem Szenario das du jetzt hast (letztes Mal was ja das Keyfile geändert worden). Vielleicht auch vom Testupdate. Dann kannst du sie vergleichen und /oder die betreffenden Zeilen hier posten. Ist das Log gezippet immer noch größer als 100k? Dann kannst du es mir notfalls auch per Mail schicken dann schua ich mal rein.

lingold

lingold
  • Members
  • 42 posts

Posted 01 February 2006 - 12:10

OK. Ich habe folgendes gemacht: Updatingversuch Hauptprojekt1 -> Hauptprojekt2, und dasselbe für VersuchsProjekt1 -> VersuchsProjekt2. Von den mehr als 20 unserer eigenen dlls, die im Merge module drin sind, haben 5 geändert, und von diesen habe ich vor dem Update-Setup (und zwar sowohl beim HP-Versuch wie auch beim VP-Versuch) 2 deregistriert und gelöscht:
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.


Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 01 February 2006 - 12:56

Im HauptProjekt2.log steht:
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)

lingold

lingold
  • Members
  • 42 posts

Posted 01 February 2006 - 13:38

Habe gesehen, welche Komponente das ist. Sie befindet sich im Bereich "SQL scripts" -> eine Connection. Ich weiss, dass ich da verschiedentlich Script entries gelöscht habe und "Insert Script files..." gemacht hatte, weil ich nichts böses dachte und gewisse Korrekturen so am besten machen konnte (und dann sicher wusste, dass das Script auch tatsächlich ausgetauscht ist). Dass jedes solche "Ding" eine Component ist, die nie gelöscht oder deren Code nicht geändert werden darf, war mir hier nicht bewusst geworden. Aber wieso wirkt sich das "quer übers ganze Setup hinweg" an einem ganz anderen Ort aus (wo ja an und für sich alles in Ordnung wäre), so dass man wochenlang an einem völlig falschen Ort sucht? Da bin ich ehrlich gesagt schon etwas geschockt. Ich werde jetzt entsprechende Änderungen vornehmen und testen, ob dann der update funktioniert.

Edited by lingold, 01 February 2006 - 14:39.


lingold

lingold
  • Members
  • 42 posts

Posted 01 February 2006 - 14:44

Es HAT funktioniert!! Nun ist wieder etwas mehr klar. Ich werde als nächsten Release mal trotzdem ein Major upgrade machen müssen, weil es sehr wahrscheinlich ist, dass wir in noch früheren Releases (die schon bei Kunden sind) weitere Male Component codes geändert hatten, vor allem bei diesen SQL scripts. Aber wenigstens ist jetzt das Wissen da. Vielen Dank!

Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 02 February 2006 - 14:46

Das Entfernen einer Komponente ist ein Verstoß gegen die Komponenten-regeln. Nach einem solchen Fehler verhält sich der Windows Installer weitgehend "undefiniert", d.h. er bekommt sämtliche Feature- und Component-State nicht mehr zuverlässig auf die Reihe. Immerhin gibt es jetzt in MSI 3 ein proeprty das man setzen kann, damit der Installer in diesem Fall abbricht anstatt Unfug zu machen (ENFORCECOMPONENTRULES or so ähnlich)