Hallo,
ich hoffe jemand kann eine Lösung dazu liefern:
Ein Setup wird sowohl für Neu- als auch für Update-Installationen genutzt. Das Update-Setup ist ein gepacktes Setup für den Download aus dem Internet. Die Neu-Installation wird über CD (ungepackt) ausgeführt.
Bestimmte Dateien sollen nur bei der Neu-Installation kopiert werden. Deshalb habe ich der Komponente eine Bedingung zugeordnet, z.B.
Bedingung: (PROGUPDATEOK="0")
PROGUPDATEOK ist eine selbstdefinierte Variable.
Zusätzlich habe ich den Schalter "Nie überschreiben" auf Ja gesetzt, um sicher zu gehen, daß vorhandene Dateien nicht ersetzt werden.
Mit InstallShield X klappt das alles wunderbar.
Dann wurde auf InstallShield 2009 umgestellt, und leider ist nichts mehr wie es war. Die Umstellung wurde hauptsächlich deshalb gemacht, weil es wegen Vista mit InstallShield X zu nicht lösbaren Problemen gekommen ist aufgrund der Benutzerkontensteuerung usw.
Auf jeden Fall klappt es mit InstallShield 2009 nicht mehr. Wird zusätzlich der Schalter "Bedingung neu auswerten" gesetzt, dann wird die Datei (z.B. eine Grafikdatei vom Typ JPG) sogar vom Zielsystem entfernt !!! Ist der Schalter "Bedingung neu auswerten" AUS, dann wird die Datei trotzdem überschrieben.
Kennt jemand eine Lösung (außer natürlich auf InstallShield X wieder umzustellen, was wir auch erstmal wieder machen, bis das Dilemma behoben ist) ???
Ist es möglich, daß selbstdefinierte Variablen durch InstallShield 2009 in Bedingungen nicht mehr akzeptiert werden ? Wenn ja, was machen Bedingungen denn dann noch für einen Sinn ???? Mal ganz davon abgesehen, ob InstallShield in dieser Form überhaupt noch Sinn macht, wenn man mehr Ärger als Nutzen davon hat ?
Vielen Dank schon mal für jeden Hinweis.
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.
Bedingung für eine Komponente
Started by
DeBo
, Feb 27 2009 14:07
7 replies to this topic
ali
-
- Full Members
- 1,008 posts
Posted 02 March 2009 - 11:35
Hallo,
leider teilst du nicht mit, um welches Update es sich handelt.
Meist genügen die Propertys die IS schon liefert wie z.B. IS_MAJOR_UPGRADE oder IS_MINOR_UPGRADE, PATCH.
Über Feature Bedingungen kann man den Installlevel setzen, es wäre also evtl. Sinnvoll speziele Komponenten in eine eigenes Feature zu hängen und dies bei verschiedenen Release evtl zusätzlich über Releaseflags einzubinden.
Eine mögliche Fehlerurach hängt aber am meisten von der Art des Updates/Upgrades ab welches du durchführst.
Wenn es sich um ein Major Upgrade handelt, könnte es auch sein, das das Problem bereits beim entfernen des alten Produktes auftritt.
Wurde mal ein log erstellt?
leider teilst du nicht mit, um welches Update es sich handelt.
Meist genügen die Propertys die IS schon liefert wie z.B. IS_MAJOR_UPGRADE oder IS_MINOR_UPGRADE, PATCH.
Über Feature Bedingungen kann man den Installlevel setzen, es wäre also evtl. Sinnvoll speziele Komponenten in eine eigenes Feature zu hängen und dies bei verschiedenen Release evtl zusätzlich über Releaseflags einzubinden.
Eine mögliche Fehlerurach hängt aber am meisten von der Art des Updates/Upgrades ab welches du durchführst.
Wenn es sich um ein Major Upgrade handelt, könnte es auch sein, das das Problem bereits beim entfernen des alten Produktes auftritt.
Wurde mal ein log erstellt?
DeBo
-
- Full Members
- 8 posts
Posted 02 March 2009 - 15:01
Hallo,
schönen Dank für die schnelle Antwort.
Es handelt sich um ein IS_MINOR_UPGRADE.
Allerdings möchte ich vermeiden, die Dateien in ein separates Feature zu verlagern, oder ist das die einzige Lösung ?
Ein Log habe ich noch nicht erstellt. Was mich eben etwas nervt, ist die Tatsache, daß es mit IS X (Premier) funktioniert und mit IS 2009 nun nicht mehr.
Witzigerweise hat es auf einem Testrechner zunächst geklappt (Win2000), auf WinXP und Vista jedoch nicht. Das hing dann von der Reihenfolge der Installation ab, d.h. wenn das usprüngliche Setup, z.B. V 3.1.0.293 mit dem Setup von V3.1.0.328 und dann mit dem aktuellen V 3.1.0.337 aktualisiert wurde, hat's nicht geklappt. Wurde V3.1.0.328 ausgelassen, hat's geklappt und die Dateien wurden weder überschrieben noch gelöscht. Aber so ein Setup kann man nicht rausgeben, wenn's mal so oder mal so geht und niemand vorhersehen kann, warum und weshalb das so ist.
Naja...ich danke dir erstmal und werde mal weiterforschen, woran es liegen könnte.
schönen Dank für die schnelle Antwort.
Es handelt sich um ein IS_MINOR_UPGRADE.
Allerdings möchte ich vermeiden, die Dateien in ein separates Feature zu verlagern, oder ist das die einzige Lösung ?
Ein Log habe ich noch nicht erstellt. Was mich eben etwas nervt, ist die Tatsache, daß es mit IS X (Premier) funktioniert und mit IS 2009 nun nicht mehr.
Witzigerweise hat es auf einem Testrechner zunächst geklappt (Win2000), auf WinXP und Vista jedoch nicht. Das hing dann von der Reihenfolge der Installation ab, d.h. wenn das usprüngliche Setup, z.B. V 3.1.0.293 mit dem Setup von V3.1.0.328 und dann mit dem aktuellen V 3.1.0.337 aktualisiert wurde, hat's nicht geklappt. Wurde V3.1.0.328 ausgelassen, hat's geklappt und die Dateien wurden weder überschrieben noch gelöscht. Aber so ein Setup kann man nicht rausgeben, wenn's mal so oder mal so geht und niemand vorhersehen kann, warum und weshalb das so ist.
Naja...ich danke dir erstmal und werde mal weiterforschen, woran es liegen könnte.
ali
-
- Full Members
- 1,008 posts
Posted 03 March 2009 - 17:51
3.1.0.337
ist das die MSI bzw. ProductVersion?
Wenn ja, dann kann ich das gar nicht so recht glauben, dass das jemals getan hat.
Hast du mal deine MSI Validiert?
"MSI property storing the product Version. Note that MSI uses only the first three fields of the ProductVersion property for version comparsions: in a.b.c.d, the field d is ignored. ...
Für Datei Versionen gilt das nicht, hier werden alle Felder verglichen.
Ist der REINSTALLMODE korrekt gesetzt, wurde der PackageCode geändert?
ist das die MSI bzw. ProductVersion?
Wenn ja, dann kann ich das gar nicht so recht glauben, dass das jemals getan hat.
Hast du mal deine MSI Validiert?
"MSI property storing the product Version. Note that MSI uses only the first three fields of the ProductVersion property for version comparsions: in a.b.c.d, the field d is ignored. ...
Für Datei Versionen gilt das nicht, hier werden alle Felder verglichen.
Ist der REINSTALLMODE korrekt gesetzt, wurde der PackageCode geändert?
DeBo
-
- Full Members
- 8 posts
Posted 04 March 2009 - 07:59
Sorry, da habe ich mich wohl etwas umständlich ausgedrückt.
Die Version ist 3.1.0., nur die zu installierende Programmversion (.exe) unterscheidet sich mit der jeweiligen Nummer (also .328 und .337, hat nichts mit MSI zu tun). Das weiß ich schon, daß hier nur die ersten 3 Stellen relevant sind und wenn die nächste Version eine 3.2.x wäre, dann würde es sich um ein MAJOR-Update handeln.
Aber der Kern der Frage wurde leider noch nicht behandelt.
WARUM HAT DAS ALLES UNTER INSTALLSHIELD X (Premier) FUNKTIONIERT UND NUN UNTER INSTALLSHIELD 2009 (Premier) FUNKTIONIERT ES NICHT MEHR ????????????
Entweder war es ein glücklicher Umstand in IS X dass es funktioniert hat, oder IS 2009 hat einen BUG, oder etwa nicht ? Oder IS X hatte einen Bug weshalb es funktioniert hat und der wurde in IS 2009 repariert. Dann muß es aber eine explizite Lösung für dieses Problem geben.
Es kann ja wohl nicht sein, daß eine Bedingung nicht oder völlig falsch ausgewertet wird. Wozu gibt es die Bedingungen für eine Komponente dann überhaupt ??? Es darf doch keine Rolle spielen, was für eine Datei hinter der Komponente steht (im speziellen Fall sind sie vom Typ JPG, INI und KEY, also nichts dramatisches).
Es kann nicht sein, daß eine Datei, die aufgrund einer Bedingung nicht kopiert werden soll, plötzlich gelöscht wird !! Da ist doch was oberfaul...
Die Version ist 3.1.0., nur die zu installierende Programmversion (.exe) unterscheidet sich mit der jeweiligen Nummer (also .328 und .337, hat nichts mit MSI zu tun). Das weiß ich schon, daß hier nur die ersten 3 Stellen relevant sind und wenn die nächste Version eine 3.2.x wäre, dann würde es sich um ein MAJOR-Update handeln.
Aber der Kern der Frage wurde leider noch nicht behandelt.
WARUM HAT DAS ALLES UNTER INSTALLSHIELD X (Premier) FUNKTIONIERT UND NUN UNTER INSTALLSHIELD 2009 (Premier) FUNKTIONIERT ES NICHT MEHR ????????????
Entweder war es ein glücklicher Umstand in IS X dass es funktioniert hat, oder IS 2009 hat einen BUG, oder etwa nicht ? Oder IS X hatte einen Bug weshalb es funktioniert hat und der wurde in IS 2009 repariert. Dann muß es aber eine explizite Lösung für dieses Problem geben.
Es kann ja wohl nicht sein, daß eine Bedingung nicht oder völlig falsch ausgewertet wird. Wozu gibt es die Bedingungen für eine Komponente dann überhaupt ??? Es darf doch keine Rolle spielen, was für eine Datei hinter der Komponente steht (im speziellen Fall sind sie vom Typ JPG, INI und KEY, also nichts dramatisches).
Es kann nicht sein, daß eine Datei, die aufgrund einer Bedingung nicht kopiert werden soll, plötzlich gelöscht wird !! Da ist doch was oberfaul...
ali
-
- Full Members
- 1,008 posts
Posted 04 March 2009 - 13:44
das kannst du rausfinden, indem du ein log schreibst. Dort könntest du schon einmal nachsehen, wie die Zustände der Komponenten während des Updatevorganges gesetzt werden.
Aber vorstellen könnte ich mir das schon, da das Minor Update im Grunde ein Reparieren der Anwendung ist, könnte es sein, das der Installer die Komponente zum erneuten installieren erst weg nimmt und dann Aufgrund der Bedingung nicht wieder hin installiert. Bzw. der Installer stellt erst fest das die Komponente entfernt wird, weil es eine neuere Version im aktuellen Paket gibt, markiert die alte Komponente als zu entfernen, wertet dann erst die Bedingung zum installieren der neuen Komponente aus und installiert diese dann nicht hin. Die alte Komponente ist dann aber weg.
Aber wie schon geschrieben, das sieht man im Log.
evtl. auch mal validieren, auch eine Upgrade Validierung
Aber vorstellen könnte ich mir das schon, da das Minor Update im Grunde ein Reparieren der Anwendung ist, könnte es sein, das der Installer die Komponente zum erneuten installieren erst weg nimmt und dann Aufgrund der Bedingung nicht wieder hin installiert. Bzw. der Installer stellt erst fest das die Komponente entfernt wird, weil es eine neuere Version im aktuellen Paket gibt, markiert die alte Komponente als zu entfernen, wertet dann erst die Bedingung zum installieren der neuen Komponente aus und installiert diese dann nicht hin. Die alte Komponente ist dann aber weg.
Aber wie schon geschrieben, das sieht man im Log.
evtl. auch mal validieren, auch eine Upgrade Validierung
Edited by ali, 04 March 2009 - 15:09.
Stefan Krueger
-
- Administrators
- 13,269 posts
InstallSite.org
Posted 12 March 2009 - 21:08
Wenn die Komponente eine Bedingung hat, die FALSE ergibt und der Haken bei "Bedingung neu auswerten" gesetzt ist, dann wird die Komponente vom Zielsystem entfernt. Das ist "by design".
Wenn die Komponente dort bleiben soll, aber nicht überschireben werden soll, dann setze "nie überschreiben". Allerdings gilt das zuerst mal für die Schlüssel-Datei der Komponente. Falls die Datei nicht als Schlüssel-Datei markiert ist, haben wir ein Problem, denn wenn du das nachträglich machst, ist kein Minor Update mehr möglich, d.h. du musst ein Major Upgrade machen.
Das unterschieldiche Verhalten zwischen InstallShield X und 2009 kann ich mir so spontan auch nicht erklären. Schreib doch mal Logdateien der beiden Varianten und schau nach den erten aller Properties und der Installationsauswahl der Komponente. Auch ein direkter Vergleich der .msi Dateien mit MsiPackageDiff könnte aufschlussreich sein.
Wenn die Komponente dort bleiben soll, aber nicht überschireben werden soll, dann setze "nie überschreiben". Allerdings gilt das zuerst mal für die Schlüssel-Datei der Komponente. Falls die Datei nicht als Schlüssel-Datei markiert ist, haben wir ein Problem, denn wenn du das nachträglich machst, ist kein Minor Update mehr möglich, d.h. du musst ein Major Upgrade machen.
Das unterschieldiche Verhalten zwischen InstallShield X und 2009 kann ich mir so spontan auch nicht erklären. Schreib doch mal Logdateien der beiden Varianten und schau nach den erten aller Properties und der Installationsauswahl der Komponente. Auch ein direkter Vergleich der .msi Dateien mit MsiPackageDiff könnte aufschlussreich sein.
Stefan Krüger
InstallSite.org twitter facebook
DeBo
-
- Full Members
- 8 posts
Posted 26 March 2009 - 16:24
Hallo,
erstmal vielen Dank für die Antworten.
Da ich aber mit den Logbüchern von InstallShield nicht wirklich viel anfangen kann, habe ich nach einer anderen Lösung gesucht und schließlich eine für mich akzeptable gefunden.
In InstallShield X musste eine Bedingung, auch wenn sie numerisch ist, in Hochkomma gesetzt werden.
Beispiel: Bedingung="1"
In InstallShield 2008/2009 wurde das geändert, da wohl der zugrunde liegende Datentyp nun Variant ist. So muß es heißen Bedingung=1.
Zumindest funktioniert das so auf mehreren Rechnern (XP und Vista, Win2000 sowieso) und es gibt auch keine seltsamen Nebeneffekte mehr (d.h. Dateien werden überschrieben oder gelöscht).
erstmal vielen Dank für die Antworten.
Da ich aber mit den Logbüchern von InstallShield nicht wirklich viel anfangen kann, habe ich nach einer anderen Lösung gesucht und schließlich eine für mich akzeptable gefunden.
In InstallShield X musste eine Bedingung, auch wenn sie numerisch ist, in Hochkomma gesetzt werden.
Beispiel: Bedingung="1"
In InstallShield 2008/2009 wurde das geändert, da wohl der zugrunde liegende Datentyp nun Variant ist. So muß es heißen Bedingung=1.
Zumindest funktioniert das so auf mehreren Rechnern (XP und Vista, Win2000 sowieso) und es gibt auch keine seltsamen Nebeneffekte mehr (d.h. Dateien werden überschrieben oder gelöscht).