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

Update bereits vorhandener Installationen


10 replies to this topic

huda

huda
  • Full Members
  • 21 posts

Posted 28 May 2015 - 16:19

Hallo,

 

ich versuche ein Setup zu erzeugen, das über eine bereits installierte Version drüberinstalliert werden kann und erhalte immer eine Meldung, dass ich die alte Version zuerst deinstallieren soll.

 

Folgende Ausgangssituation ist gegeben:

- Wir nutzen InstallShield 2014 Professional Edition
- Basic MSI Projekt
- Es existiert bereits ein Vorgängersetup
- Es wurden im neuen Setup nur wenige Dateien geändert bzw. hinzugefügt
- PackageCode wurde geändert -> Small Upgrade
- Funktion "Build SINGLE_MSI_IMAGE" wird aufgerufen um .msi-Datei zu erzeugen
 

Folgendes Ziel soll erreicht werden:
- .msi-Datei
- 1 Setup, das sowohl für Neuinstallation (full installation) als auch als Upgrade genutzt
  werden kann:
  => Falls noch keine Version installiert ist, dann soll komplettes Setup installiert werden (Neuinstallation).
  => Falls Vorgängerversion existiert, dann sollen die geänderten Dateien über die existierende Version drüberinstalliert werden.

 

Problem:
Wenn das Vorgängersetup bereits installiert wurde und jetzt das neue Setup drüberinstalliert werden soll, dann kommt immer folgende Fehlermeldung:
  Eine weitere Version dieses Produkts ist bereits installiert. Die
  Installation dieser Version kann nicht fortgesetzt werden. Verwenden
  Sie die Systemsteuerungsoption "Programme und Funktionen", um die
  installierte Version dieses Produkts zu konfigurieren oder zu entfernen.
 

In der LOG-Datei steht folgendes:

 PROPERTY CHANGE: Adding PackagecodeChanging property. Its value is '1'.
Eine andere Version des Produkts ist bereits installiert. Die Installation dieser Version kann nicht fortgesetzt werden. Verwenden Sie die Systemsteuerungsoption "Software", um die vorhandene Version dieses Produkts zu konfigurieren oder zu entfernen.
{165A328D-438F-458B-9B89-CFC458BD2330}
 

In anderen Beiträgen habe ich gelesen, dass man nur den PackageCode ändern muss, um ein Small Upgrade zu erzeugen. Warum kommt dann diese Meldung? Muss ich noch etwas bei Media->Upgrades definieren?

 

Unabhängig davon hätte ich noch eine andere Frage:

Kann man die msi-Datei nachträglich umbenennen (z.B. eine Versionsnummer einfügen) oder funktioniert dann der Updatemechanismaus nicht mehr?

 

Ich würde mich sehr freuen, wenn mir jemand helfen könnte. Vielen Dank schon mal.

 



Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 03 June 2015 - 14:39

Verwende die setup.exe zum Starten des Setups. Small und Minor Updates kann man nicht durch reines Anklicken der .msi Datei installieren, dazu müsste man Kommandozeilenparameter mitgeben (und genau das macht die setup.exe).

Wenn du den Namen der .msi Datei ändern willst musst du ein Major Upgrade machen.



huda

huda
  • Full Members
  • 21 posts

Posted 09 June 2015 - 11:26

Danke für die Antwort. Leider bin ich was InstallShield angeht noch ein Anfänger (habe bis jetzt mit InstallJammer gearbeitet) und in der Schulung sind wir nicht wirklich auf die Upgrade-Problematik eingegangen.

Mir ist daher nicht ganz klar, wie ich eine Setup.exe verwenden soll, wenn mir das Build eine .msi-Datei liefert. Oder kann man sich zusätzlich eine Setup.exe erzeugen lassen? Wenn ja, wie?

Unsere Kunden benötigen eine .msi-Datei für die automatische Installation/Verteilung der Software auf mehreren Rechnern. Geht das dann nicht mit einem Small- oder Minor-Upgrade?



Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 10 June 2015 - 17:42

Du kannst im Build Wizard auswählen, dass eine setup.exe erzeugt werden soll.



huda

huda
  • Full Members
  • 21 posts

Posted 18 June 2015 - 16:00

Hallo Stefan,

 

ich habe jetzt 2 verschiedene Varianten von setup.exe ausprobiert.

1. CD-ROM Format

2. Web Format

 

Im ersten Fall erhalte ich eine setup.exe, 2 .ini-Dateien und eine .msi-Datei.

Im zweiten Fall erhalte ich nur eine setup.exe

 

Leider funktioniert weder die eine noch die andere Variante. In beiden Fällen erhalte ich folgende Fehlermeldung:

"Das angegebene Konto ist bereits vorhanden."

Das Setup wird beendet, ohne dass etwas installiert wurde.

 

Was habe ich falsch gemacht?

 

Außerdem bin ich mir gar nicht sicher, ob unsere Kunden mit so einer setup.exe Datei eine automatische Verteilung auf verschiedenen Rechnern machen können. Die Vorgabe für uns lautete eigentlich eine .msi-Datei zur Verfügung zu stellen. Oder ist in der setup.exe eine .msi-Datei "versteckt", so dass die automatische Verteilung trotzdem funktioniert?

 

Oder bleibt mir nichts anderes übrig, als immer ein Major-Release zu machen?

 

Beim Durchlesen des gesamten Themas ist mir folgender Satz von dir aufgefallen:

"Small und Minor Updates kann man nicht durch reines Anklicken der .msi Datei installieren, dazu müsste man Kommandozeilenparameter mitgeben"

Wenn noch keine Installation existiert, bzw. wenn ich eine vorhandene deinstalliere, dann funktioniert das bei mir und zwar einfach per Doppelklick auf die .msi-Datei. Da ich nur den PackageCode geändert habe, müsste es doch ein SmallUpdate sein, oder?

 

Ich freue mich über jeden Tipp, der mich weiterbringt.



Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 18 June 2015 - 16:51

Die Meldung mit dem Konto ist wirklich seltsam, da müsste man mal genauer schauen ob die wirklich von der setup.exe kommt.

 

In der setup.exe steckt eine .msi, die zunächst entpackt wird und dann gestartet wird. Bei einem Verteilsystem ist die seup.exe Lösung eher nicht optimal.

 

Grundsätzlich:

Wenn das Produkt nicht installiert ist, kannst du die Installation durch Doppelklick auf die msi-Datei starten. Wenn es aber schon vorhanden ist, d.h. du willst das neue msi als (Small oder Minor) Update installieren, dann kommt beim Doppelklick nur die Meldung, dass eine andere Version bereits installiert ist und zuvor entfernt werden muss. Dafür gibt es verschiedene Lösungsansätze:

  • Kommandozeile: msiexec.exe /i dein.msi REINSTALLMODE=vomus REINSTALL=ALL (das funktioniert aber nur beim Update, nicht bei der Erstinstallation). Evtl. kann das auch das Verteilsystem erledigen.
  • setup.exe die prüft, ob das Produkt schon installiert ist und dann nach Bedarf das msi mit oder ohne die o.g. Kommandozeile startet.
  • Neue Version nicht als vollständige msi verteilen sondern daraus einen Patch (msp) erzeugen.
  • altes msi vorher deinstallieren (ggf. über das Verteilungssystem)
  • Major Upgrade machen, d.h. ProductCode ändern und einen Major Upgrade Eintrag in der Upgrade Ansicht anlegen.


huda

huda
  • Full Members
  • 21 posts

Posted 18 June 2015 - 17:54

Danke für deine Hilfe.

Da wir über kurz oder lang auch Patches (msp) zur Verfügung stellen möchten, wird das sicher eine Option sein. Aber auch die anderen Alternativen kommen evtl. bei den Kunden in Betracht. Fürs erste werde ich mich für die Variante mit dem Major Upgrade entscheiden, da das vermutlich am schnellsten und einfachsten realisierbar ist. Außerdem können wir dann auch die Versionsnummer in den .msi-Dateinamen schreiben, auch wenn sie sich jedesmal ändert.



huda

huda
  • Full Members
  • 21 posts

Posted 16 September 2016 - 11:28

Hallo Stefan,

vielleicht kannst du mir nochmal helfen?

 

1.

Ich habe bisher aus meiner IS-Projektdatei immer ein MajorRelease erzeugt. Das bedeutet, dass ich immer den ProductCode geändert habe und dass immer ein Major Upgrade Eintrag definiert ist. Wenn ich jetzt aus der gleichen Projektdatei ein Small oder Minor Update machen möchte, reicht es dann aus, den ProductCode nicht zu ändern? Oder muss ich auch den Major Upgrade Eintrag löschen?

 

2.

Wir haben 4-stellige Versionsnummern (die vierte Stelle ist die Fehlerpatchnummer oder auch Buildnummer). Wenn ich richtig informiert bin, dann kann ich kein Major Upgrade machen, wenn sich nur die vierte Stelle ändert, oder?

Wenn ich also den PackageCode und den ProductCode ändere, die Versionsnummer aber nur an der vierten Stelle, um was für ein Release handelt es sich dann?

Wenn ich zwei msi-Dateien mache mit genau diesen Änderungen und sie nacheinander installiere, dann erscheinen in der Windows-Systemsteuerung "Programme und Funktionen" beide Versionen parallel (10.2.2.4 und 10.2.2.5). Es soll hier aber nur die neueste Version erscheinen.

 

3.

Ich habe auch noch einen ISPreventDowngrade-Eintrag. Dabei ist die Minimum Version die aktuelle Versionsnummer (10.2.2.5). Die Maximum Version ist leer. Kann ich damit verhindern, dass Version 10.2.2.4 über 10.2.2.5 drüberinstalliert werden kann? Oder geht das auch nicht mit 4stelligen Versionsnummern? Gäbe es noch eine andere Möglichkeit zu verhindern, dass 10.2.2.4 über 10.2.2.5 drüberinstalliert werden kann?

 

4.

Bei uns ändern sich häufig DLL-Dateien (nie nicht automatisch registriert werden -> SHARED=No). Die DLL's haben immer die gleiche Versionsnummer. Ich hatte schon Probleme beim Updaten, dass die geänderten DLL's vom Setup nicht kopiert wurden. Liegt das an der unveränderten Versionsnummer? Wieviele Stellen darf denn eine DLL Versionsnummer haben, um von IS als geändert erkannt zu werden? Kann man hier mehr als 3 Stellen verwenden?

 

5.

Wir würden gern msp-Dateien für die Fehlerpatches erzeugen. Brauche ich dazu 2 Major Upgrades? Kann ich ein Major Upgrade 10.2.2.4 und ein 10.2.2.5 machen und daraus eine msp-Datei erzeugen? Wenn ja: muss ich beim ersten Major Upgrade etwas bestimmtes einstellen/beachten, um später eine msp-Datei erzeugen zu können? Oder geht das auch nicht mit 4stelligen Versionsnummern? Gibt es überhaupt eine Möglichkeit msi-Setups upzudaten, wenn man 4stellige Versionsnummern verwendet?

 

Vielen Dank schon mal für jede Hilfe!


Edited by huda, 16 September 2016 - 11:59.


Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 21 September 2016 - 06:45

Hallo huda,

 

1. Wenn du den ProductCode nicht änderst, wird der MajorUpgrade Eintrag ignoriert. D.as bedeutet auch, dass das selbe Setup beides sein kann: ein Minor Update z.B. für die Vorgängerversion mit gleichem ProductCode und ein Major Upgrade für eine ältere Version mit anderem Product Code (aber gleichem Upgrade Code).

 

2. Wenn du die Version nicht in einem der ersten drei Felder änderst hast du ein "kaputtes" Major Upgrade, das nicht richtig funktioniert. Deshalb steht in der Doku, dass man die Version ändern muss.

 

3. Hier wird der Major Upgrade Mechanismus verwendet, d.h. es werden nur neue Versionen mit anderem ProductCode erkannt. Der Eintrag verhindert also sozusagen nur "Major Downgrades", aber nicht "Minor Downgrades". Wenn du den ProductCode änderst, aber in der ProductVersion nur die 4. Stelle, ist dein Setup fehlerhaft (siehe Frage 2). Ich weiß nicht genau, was dann passiert.
Wenn du den ProductCode nicht änderst, gelten ja weiterhin die Dateiversionsregeln, d.h. Windows Installer wird eine neuere Datei nicht durch eine ältere ersetzen. Deine 10.2.2.5 Dateien bleiben also unverändert, auch wenn 10.2.2.4 drüber installiert wird. Ich bin jetzt nicht ganz sicher, wie die setup.exe sich in dem Fall verhält, ob sie das verhindert - müsste man mal ausprobieren.

Wenn du selbst so etwas einbauen willst, könntest du über die Systemsuche nach einer Datei (z.B. deiner Haupt-EXE) suchen mit der aktuellen Version+1 als Minimum-Version. Wenn die Suche erfolgreich ist, weißt du, dass eine neuere Version vorhanden ist und kannst die Instalaltion abbrechen. Das funktioniert natürlich nur, wenn die Version dieser EXE jedes Mal hochgezählt wird. Und du musst den Eintrag bei jedem release ändern.

 

4. Bei Dateiversionen zählen alle Stellen. Sie sollte bei jeder (veröffentlichten) Änderung hochgezählt werden. Die Beschränkung auf die ersten 3 Stellen gilt nur für die ProductVersion.

 

5. Patches werden normalerweise für Minor oder Small Updates erzeugt, nicht für Major Upgrades. Du musst die neue Version erzeugen und dann bei der Patch-Erstellung die MSI-Datei der alten Version angeben, damit InstallShield die geänderten Dateien ermitteln kann. Wenn es nur um einen Hotfix geht, kann man auch mal ein QuickPatch-Projet erzeugen. Das sollte aber die Ausnahme sein, denn wenn man viele Quickpatches draußen hat, ist es kompliziert die bei späteren Updates wieder "einzufangen".

Falls du tatsächlich ein msp für ein Major Upgrade erstellen möchtest (was laut Doku zwar nicht ausdrücklich verboten ist, aber eigentlich auch nciht wirklich vorgesehen), dann brauchst du ein gültiges Major Upgrade, also Änderung der ProductVersion in den ersten drei Stellen.



huda

huda
  • Full Members
  • 21 posts

Posted 22 September 2016 - 11:57

Vielen Dank für die Antworten, dadurch ist mir einiges klarer geworden.

Vermutlich sind meine "kaputten" Major Upgrades verantwortlich dafür, dass ich in der Windows-Systemsteuerung 2 Einträge bekomme.

 

Noch eine kurze Nachfrage zu 1, ob ich das auch richtig verstanden habe:

Ob es sich um ein Major oder Minor Upgrade handelt wird also erst bei der Installation entschieden. Wenn eine Version mit dem gleichen ProductCode gefunden wird, reagiert das Setup wie ein Minor Upgrade, wenn eine Version mit unterschiedlichem ProductCode gefunden wird (aber gleichen UpgradeCode), reagiert das Setup wie ein Major Upgrade? Ist das korrekt?



Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 26 September 2016 - 18:03

Ja, das ist so richtig.