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

Reparaturfunktion abschalten


18 replies to this topic

fzmb_dev

fzmb_dev
  • Members
  • 13 posts

Posted 24 June 2003 - 08:21

Wie kann ich die Reparaturfunktion abschalten? Jedesmal, wenn sich unter W2K ein anderer Benutzer anmeldet startet beim Programmaufruf ein MSI-Fenster und versucht was zu reparaieren. Es ist aber alles ok, also soll er das gefälligst lassen. Also wie kann ich das Dingens abschalten?

Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 24 June 2003 - 08:43

Finde heraus, was in deinem Setup die reparatur auslöst und korrigiere das. In der Ereignisanzeige sollte ein Eintrag sein, der auf die Problemursache hinweist. Oder du aktivierst das Logging via Registry-Eintrag.
(mit anderen Worten: es handelt sich um einen Fehler in deinem Setup, den du beheben solltest, anstatt das Symptom zu verbergen)

fzmb_dev

fzmb_dev
  • Members
  • 13 posts

Posted 24 June 2003 - 08:55

Das Problem ist längst gefunden. Es ist der besagte Temp-Pfad. Beim Administrator liegt der im Profilverzeichnis. Der Windows Installer merkt sich seinen Temp-Pfad "hart", fragt also bei der Reparatur unter einem anderen Benutzer nicht die aktuelle Systemvariable ab sondern versucht in das Temp-Verzeichnis vom Admin zu schreiben, wo er natürlich keine Rechte hat. Also wie bringe ich dem Dingens bei, wo er sein Temp-Verzeichnis zu suchen hat?

PS: Wo finde ich den besagten Registry-Eintrag?

Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 24 June 2003 - 15:53

Warum muss das Setup überhaupt in den Temp-Pfad schreiben? Werden dei Dateien dort für den Benutzer benötigt? Wenn nicht, dann sollten sie nicht als Schlüsselpfad der Komponente gekennzeichnet sein.

Zur Protokollierung siehe http://www.msifaq.de/a/1022.htm


fzmb_dev

fzmb_dev
  • Members
  • 13 posts

Posted 25 June 2003 - 15:37

Ich hab dem InstallShield nicht gesagt, daß er da was inschreiben soll. Ich hab ein ganz normales, assistentengestütztes Projekt erstellt, die Programmdateien hinzugefügt und Verknüpfungen definiert, die im Startmenü und auf dem Desktop erscheinen sollen. Alles keine weltbewegenden Sachen. Und mit dem Temp-Pfad hab ich gar nichts am Hut. Also vermute ich mal, daß das MSI von sich aus dort irgendwas zu tun versucht. Oder der InstallShield definiert per Standard irgendwas mit dem Temppfad. Ich weiß es nicht.

Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 25 June 2003 - 16:17

Trotzdem sollte beim Anmelden eines neuen users kein Repair ausgeführt werden - ausser du hast das in deinem Setup so eingebaut, z.B. einen Registry-Eintrag in HKCU als Schlüsselpfad einer Komponente markiert. Dazu müsste aber wie gesagt etwas im Ereignisprotokoll stehen ("Erkennung der Komponente X Produkt Y fehlgeschlagen..." oder so ähnlich)

fzmb_dev

fzmb_dev
  • Members
  • 13 posts

Posted 26 June 2003 - 11:55

Ja, genau sowas sagt er: "Erkennung von Produkt {Lange Nummer}, Funktion "AllFiles" und Komponente {Noch ne lange Nummer} fehlgeschlagen. Die Ressource "C:\DOKUME~1\ADMINI~1\LOKALE~1\Temp\" ist nicht vorhanden."

Inzwischen habe ich das Problem vielleicht entdeckt und behoben. Ich habe alle vom Assistenten angelegten Verknüpfungen gelöscht und von Hand neu angelegt. Ursprünglich stand in dem Feld für Zielpfad "[Angebotene Komponente]\xyz.exe", das habe ich nun auf "[INSTALLDIR]\xyz.exe" gestellt. Damit tritt keine Repair-Funktion unter Win 2000 mehr auf. Nur kreidet er mir das jetzt bei der Validierung als Warnung an. Aber auf die Validierung geb ich erstmal nicht so viel, wir kleben eh kein Designed-for-Windows-Logo auf die CD.

Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 26 June 2003 - 16:29

Die erste lange Nummer ist der Produkt-Code. Schau mal, ob das dein Produkt ist. (Allgemeine Einstallungen -> Produkteigenschaften)
Die zweite ist die Komponenten-ID die als beschädigt erkannt wird. (steht in den Eigenschaften der Komponenten)

Durch deine Maßnahme überprüft der Installer jetzt nicht mehr, ob die Installation noch in Ordnung ist, d.h. kein Auto-Repair. Das gilt aber nur für die Verknüpfungen. Ein Auto-Repair kann auch auf andere Weise ausgelöst werden, z.B. COM Aktivierung. Also am besten schaust du dir den Schlüsselpfad der bemängelten Komponente mal an bzw. postest hier die Einstellungen.

fzmb_dev

fzmb_dev
  • Members
  • 13 posts

Posted 27 June 2003 - 09:14

Warte mal, das versteh ich jetzt nicht. Wenn ich das mit der "Angebotenen Komponente" eintrage, startet bei W2k eine Repair-Funktion, bei "INSTALLDIR" nicht. Wenn die Zieldatei aber in beiden Fällen vorhanden ist, was kann er dann reparieren wollen?

Und was meinst du mit Schlüsselpfad? Wo finde ich den?

Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 27 June 2003 - 09:26

Schlüsselpfad ist entweder eine Datei, ein Registry-Eintrag oder das Zielverzeichnis einer Komponente. Gekennzeichnet durch das Schlüssel-Symbol.

Wenn deine Applikation durch einen "advertised" Shortcut oder COM-Aktivierung geladen wird, dann prüft der Installer alle Schlüsselpfade und startet ein Repair, falls was fehlt. Das passiert also nicht nur, wenn eine Datei gelöscht wurde, sondern auch wenn ein Registry-Eintrag oder ein Verzeichnis fehlt, sofern es sich um den "Schlüsselpfad" einer Komponente handelt.

Typischerweise passiert das, wenn ein HKEY_CURRENT_USER Eintrag als Schlüsselpfad markiert ist. Wenn der User sich zum ersten Mal anmeldet, ist dieser nicht vorhanden und triggert ein Repair.

Wenn in einer Komponente kein Schlüsselpfad angegeben ist, wird automatisch das Verzeichnis verwendet. Wenn du also eine Komponente hast, die als Zielverzeichnis das Temp-Verzeichnis verwendet, kann das ebenfalls passieren.

Übrigens muss das Problem nicht notwendigerweise in deinem Haupt-Setup liegen sondern evtl. in einem Merge Modul. Wenn du eine Validierung deines Setups durchführst (nachdem du die Shortsuts wieder auf "advertised" umgestellt hast) sollstest du eine entsprechende Warnung bekommen.

fzmb_dev

fzmb_dev
  • Members
  • 13 posts

Posted 27 June 2003 - 10:44

Dann kann es eigentlich nur am BDE Merge Modul liegen. Ist das einzige, das ich verwende. Das Temp-Verzeichnis verwende ich selbst nicht, habe nichts derartiges eingestellt. Ich kann es mir nur durch einen Default beim Erstellen des Setups erklären, doch ich finde nichts.

Wenn das Repair nur beim ersten Mal käme, wenn sich ein neuer Benutzer anmeldet, würde ich sagen, o.k., daß es so. Aber das Repair kommt bei jedem Aufruf des Programms. Also klappt auch die Reparatur nicht richtig.

Vielleicht sollte ich noch erwähnen, daß das zu installierende Programm sehr einfach gestrickt ist. Eine EXE, ein paar DLL's, die alle nur ins Zielverzeichnis müssen und mehr nicht. Ich verwende kein COM, ActiveX oder sonstiges. Und wenn einer ne Datei im Installationsverzeichnis von Hand löscht dann muß er auch mit den Konsequenzen leben und von Hand neu installieren. Von daher bin ich auf eine Repair-Funktion nicht angewiesen, zumal es mit der Angabe von "INSTALLDIR" keine Probleme gibt. Also kann sich der Reparaturversuch doch nur mit InstallShield-eigenen Dingen befassen, nicht mit dem eigentlichen Programm. Oder sehe ich das falsch?

Ich bitte, mich nicht falsch zu verstehen. Ich finde den Windows Installer schon ein sehr nützliches Werkzeug. Nur verstehe ich den Sinn mancher Eigenheiten nicht.

Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 27 June 2003 - 16:24

Klarheit bekommen wir nur, wenn wir heraus finden, zu welcher Komponente die GUID im Ereignisprotokoll gehört. Am einfachsten öffnest du die .msi Datei (nicht die .ism) mit Orca oder im Direct Edit Modus von InstallShield. Dort in der Tabelle Component sind alle Komponenten mit Name und GUID aufgeführt.
Es kann natürlich am BDE Modul liegen, obwohl mir dieses problem bisher nicht bekannt war.

fzmb_dev

fzmb_dev
  • Members
  • 13 posts

Posted 30 June 2003 - 14:45

Die in der Fehlermeldung genannte GUID bezieht sich auf die Komponente "AllFiles", in der ich alle zu installierenden Dateien abgelegt habe.

Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 30 June 2003 - 19:40

Das heisst, Feature und Komponente haben den gleichen Namen, nämlich AllFiles. Was ist den als Schlüsselpfad für diese Komponente markiert (falls überhaupt irgend was)? Und welches Zielverzeichnis ist angegeben?

Übrigens besagen die Komponenten-Tregeln, dass jede EXE, DLL, OCX u.ä. in eine eigene Komponente müssen. Alle Dateien zusammen in eine Komponente zu packen ist nicht sinnvoll

fzmb_dev

fzmb_dev
  • Members
  • 13 posts

Posted 01 July 2003 - 08:33

Sekunde, Kommando zurück. Jetzt hab ich Käse erzählt. "AllFiles" ist ein Feature, unter dem ich alle Dateien organisiert habe. Der Assistent hat, so wie du es sagst, für jede DLL und EXE eine eigene Komponente angelegt.

Die genaue Fehlermeldung lautete:

"Erkennung von Produkt "{9EF0A670-9DAE-4CBD-9BD4-8FEDC1A02204}", Funktion AllFiles" und Komponente "{315BD88B-0C03-11D4-9521-00C04FB1760A}" fehlgeschlagen. Die Ressource "C:\DOKUME~1\ADMINI~1\LOKALE~1\Temp\" ist nicht vorhanden."

Die Nummer vom Produkt stimmt mit der überein, die ich für das Projekt vergeben habe. Aber die besagte Komponenten-Nummer finde ich bei keiner unter "Komponenten" eingetragenen Komponente.

Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 01 July 2003 - 09:55

QUOTE (fzmb_dev @ 2003-07-01 09:33)
Aber die besagte Komponenten-Nummer finde ich bei keiner unter "Komponenten" eingetragenen Komponente.

Auch nicht, wenn du die .msi Datei im Direct Edit Modus oder in Orca öffnest?

fzmb_dev

fzmb_dev
  • Members
  • 13 posts

Posted 01 July 2003 - 15:48

Auch da finde ich nur eine Übereinstimmung bei der Produkt-Nummer, aber die Komponenten-Nummer finde ich nirgends. Allerdings finde ich für das BDE-Modul an sich auch keiner Komponenten-Nummer. Wo muß ich da gucken?

dq-soft

dq-soft
  • Full Members
  • 11 posts

Posted 16 October 2007 - 13:40

Hallo zusammen,

gab es damals eigentlich eine Lösung für dieses Problem?

Ich frage, weil ich heute exakt das gleiche Problem.

Auch bei mir ist der Auslöser für den Repair Versuch das fehlende Admin-Temp Verzeichnis. Die erste ID ist die meines Setup, die zweite ID ist exakt die selbe wie in diesem Thread beschrieben.

Ich verwende Installshield 2008 Premium, Basic MSI Projekt, BDE-Ent.MSM. Projekt mit Projektassistent aufgesetzt.

Der Fehler tritt immer dann auf, wenn ich das Setup als Admin installiere und dann als normaler Anwender das installierte Programm starte, sowohl unter XP als auch unter Vista.

Verwendet werden von mir ausschließlich Unterverzeichnisse in folgende Pfaden : [ProgrammFilesFolder], [CommonFilesFolder]. Das einzige Merge-Modul, dass ich verwende ist BDE-Ent Version 5.1.1 aus Delphi 6.00 Enterprise. (Tratt auch bei der "aktuellen" BDE-Pro Version 5.1.1 aus Delphi 2007 Architect auf)

Nach Bestätigung der Fehlermeldung "BDE Merge Error" startet das Programm. Weitere Starts funktionieren dann einwandfrei.

Viele Grüße
Dirk



dq-soft

dq-soft
  • Full Members
  • 11 posts

Posted 17 October 2007 - 11:24

Hallo zusammen,

Ich habe die Lösung inzwischen selbst gefunden:

In der BDE-Ent.msm habe ich in Component den TempFolderFiles Eintrag von TEMP auf ALLUSERSPROFILE umgesetzt und in Directory AllUSERSPROFILE mit TARGETDIR und .:ALLUSE~1|All Users angelegt.

Damit sind die Probleme behoben.

Anscheinend müssen für einen anderen User Daten oder Dateien aus dem Merge-Modul angepasst werden, ich vermute idapi.cfg. Dazu benötigt der Installer anscheinend die entpackten Merge Modul Daten aus dem temp Verzeichnis.

Vieleicht wird auch einfach beim Programmstart nur überprüft, ob der Pfad zu den Temp Dateien vorhanden ist.

Da dieser bei jedem User jedcoch anderes liegt kann der Installer sie dann nicht mehr finden und entpackt das Merge Modul neu, ändert die Temp-Pfadangabe und führt seine Änderungen durch. Wechselt man nun wieder den User geht das Spielchen von vorn los.

Mit der obigen Änderung werden dié Temp Daten in das Verzeichnis abgelegt, das für aller Anwender zugänglich ist. Somit werden sie auch sofort gefunden.

Viele Grüße
Dirk