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

Probleme mit Aktualisierung von Dateien


7 replies to this topic

SteHoh

SteHoh
  • Members
  • 10 posts

Posted 05 December 2005 - 10:48

Hallo,
wir müssen einen Installer für eine CD-ROM-Reihe erstellen. Kauft sich der Kunde eine CD, wird diese ganz normal installiert. Sobald er weitere Titel der Reihe hinzufügt, sollen diese in den bestehenden Ordner integriert werden und unter einer gemeinsamen Oberfläche erscheinen.
Die jeweils höchste Version der Reihe enthält die aktuellsten Dateien für die Programmoberfläche und die akutelle Konfiguration als XML-Datei.
Wir haben natürlich keinen Einfluß auf die Installationsreihenfolge. D. h. installiert der Kunde erst Titel 3, gefolgt von Titel 1, sollen nur die fehlenden Module von Titel 1 installiert werden. Andersherum soll aber zusätzlich die Programmoberfläche und die XML aktualisiert werden.
Leider klappt es bei uns nicht, dass die .exe durch eine aktuellere Version überschrieben wird, selbst wenn ich im Setup-Design die Dateiversion erhöhe. Die .exe ist als Schlüsseldatei des Features definiert. Wenn ich es ohne Schlüsseldefinition versuche, klappt es. Dafür wird nun die XML-Datei immer überschrieben. Dies geschieht immer, selbst wenn ichdie XML als Schlüssel definiere. "Immer überschreiben" geht nicht, da sonst eine ältere Version die falsche Konfigurationsdatei installieren würde.
Zusätzliches Problem: Bisher tauchen alle Produkte einzeln unter "Software" auf. Bei der Deinstallation eines Tiels wird aber die XML deinstalliert, so dass die Produktreihe nicht mehr funktionsfähig ist. Als Workaround würde es zur Not reichen, die Verknüpfungen vom Desktop und aus dem Startmenü zu löschen. Eine saubere Deinstallation aller Titel wäre natürlich besser.
Da wir vom Kunden einen gewissen Rahmen für den Installer vorgegeben bekommen, sollte dies möglichst als reines MSI-Projekt funktionieren, ohne zusätzliches Installscript.
Da wir keine Fulltime-InstallShield-Programmierer sind, treten wir gerade auf der Stelle. Kann uns jemand Tipps zur richtigen Vorgehensweise geben?
Gruß
SteHoh

Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 05 December 2005 - 16:06

Wenn gleiche Dateien (auch unterschiedliche Versionen davon) von mehreren Setups ins gleiche Verzeichnis installiert werden sollen, dann muss jeweils die gleiche ComponentCode GUID verwendet werden. Das kann man z.B. über Merge Module sicherstellen.

SteHoh

SteHoh
  • Members
  • 10 posts

Posted 05 December 2005 - 16:12

Vielen Dank für Ihre Antwort.
Dann werde ich mich also erst einmal schlau machen was Merge Module sind und wie ich damit arbeite und mich dann gegebenenfalls später nochmals zurück melden.
Gruß
SteHoh

SteHoh

SteHoh
  • Members
  • 10 posts

Posted 27 January 2006 - 13:12

Hallo,
nach längerer Pause beschäftige ich mich wieder mit dem Problem.
Wir arbeiten stets mit duplizierten Installerdateien (.ism), so dass wir sicher stellen können, dass immer die gleiche Komponenten-ID verwendet wird. Wir ändern jeweils Produkt-, Paket- und Upgrade-ID, sowie den Produktnamen.

Bei allen bisherigen Versuchen, haben wir es trotz gleicher Komponenten-ID nicht geschafft, dass neuere Dateiversionen nicht überschrieben werden. Anscheinend funktioniert noch nicht einmal die Versionsverwaltung über die Schlüsseldatei. Selbst wenn die Schlüsseldateien (die EXE bzw. die XML-Datei) ein neueres Datum haben, wird die zugehörige Komponente immer installiert. (Die Komponenteneigenschaft "gemeinsam genutzt" wurde natürlich gesetzt.) Inzwischen bin ich völlig ratlos, weil das Verhalten des Installers überhaupt nicht den Beschreibungen in der Hilfe entspricht.
Gruß
SteHoh

Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 27 January 2006 - 18:10

Das *Datum* ist weitgehend egal, Windows Installer vergleicht die *Versionsnummer*. Wenn du den ProductCode änderst handelt es sich um ein sog. Major Upgrade. Da ist die Standardeinstellung dass zuerst 8automatisch) die alte Version deinstalliert wird und dann die neue Verison installiert wird. Dann werden natürlich alle Dateien erstezt, denn es findet ja eigentlich kein "Überschreiben" sondern ein "Löschen+ Neu schreiben" statt. Das kann mna aber in den Upgrade-Einstellungen ändern, so dass auch beim Major Upgrade erst die neuen Dateien kopiert werden.

SteHoh

SteHoh
  • Members
  • 10 posts

Posted 30 January 2006 - 13:28

Hallo,
danke erst mal für deine Antwort.
Hier nochmals zwei Probleme:
1) Bei uns verhalten sich die Installationen bisher wie völlig getrennte Produkte, d.h. sie tauchen unter "Software" einzeln auf. Das ist nicht unsere Idealvorstellung, aber besser haben wir es mit der uns zugelieferten Vorlage nicht hinbekommen. Wir haben also keine Upgrades, sondern getrennte Installationen, die in den gleichen Ordner schreiben. Ich habe es bereits mit kleinen Updates versucht (nur die Paket-ID geändert). Leider habe ich aber bisher nicht herausgefunden, wie ich eine Installation mit geringerer Versionsnummer zwingen kann, nur fehlende Dateien einzuspielen und existierende Dateien in Ruhe zu lassen (REINSTALL). Wenn ich es richtig verstanden habe, gibt es über die Kommandozeile eine Möglichkeit, genau dies zu erreichen. Wie bekomme ich diese Einstellung beim Build automatisch in die Setup.ini eingetragen? Oder wie kann ich sonst ein Setup bauen, dass immer mit dieser Einstellung gestartet wird?

2) Die InstallShield Online-Hilfe suggeriert, dass eine Schlüsseldatei entscheidet, ob eine Komponente installiert wird oder nicht. Nun habe ich ein Komponente die eine statische Datei (die EXE als Schlüsseldatei), sowie eine dynamische Verknüpfung zu den Unterordnern und -dateien enthält. Da unser Entwicklertool immer die gleiche Versionsnummer in die EXE schreibt, habe ich diese mit einem Resourceneditor gepatched. InstallShield erkennt jetzt, dass die EXE als Schlüsseldatei neuer ist - aber alle weiteren Dateien der Komponente werden trotzdem installiert. So werden neuere Dateien überschrieben. Wenn die SChlüsseldatei nicht das tut, was sie tun soll, wozu kann ich diese überhaupt gebrauchen?
Für mich ist InstallShield ein sehr mächtiges Werkzeug, aber ein grauenhaft schlecht dokumentiertes. Schade, dass man nicht ohne Expertenhilfe so banale Dinge wie "überschreibe keine neueren Dateien" hinbekommt (zumindestens bei der Verwendung von Basic MSI).
Gruß
SteHoh

SteHoh

SteHoh
  • Members
  • 10 posts

Posted 31 January 2006 - 12:40

Problem gelöst. Wir setzen jetzt in der Registry eine Versionsnummer. Jedes Produkt trät als Eigenschaft die Produktnummer. Die Komponente des Rahmenprogramms bekommt eine Bedingung, die die Versionsnummer aus der Registry mit der gesetzten Eigenschaft vergleicht. Ist die Eigenschaft kleiner oder gleich der Versionsnummer, wird die Komponente nicht installiert und die Versionsnummer in der Registry bleibt unangetastet.
Warum man aber solche unglaublichen Klimmzüge machen muss, um eine völlig banale Funktionalität zu erreichen... Eigentlich sollte dies ja (laut Hilfe) mit den Schlüsseldateien funktionieren. Wozu ich diese dann überhaupt brauche, ist mir inzwischen völlig unklar.
Gruß
SteHoh

Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 01 February 2006 - 09:48

Ja, mit den Schlüsseldateien sollte das funktionieren - allerdings natürlich nur für die Komponenten in der die EXE die Schlüsseldatei ist. Wenn du aber Unterverzeichnisse dynamisch einbindest (und nicht nur den Inhalt eines Verzeichnisses) dann muss InstallShield dynamisch weitere Komponenten anlegen (denn alle Dateien einer Komponente müssen ins gleiche Verzeichnis, das ist eine Windows Installer Anforderung). Und diese automatisch erzeugen Komponenten haben dann natürlich keine Schlüsseldatei. Besser ist es, manuell für jedes Unterverzeichnis eine Komponente anzulegen.

Generell besteht die Schwierigkeit darin, dass deine Überschreib-Regeln anders aussehen als Microsoft sich das gedacht hat als sie den Widows Installer entworfen haben.