Prüfmethoden für Updates

[TheMiller]

Hallo und danke für die vielen Antworten. Konnte leider nicht eher antworten - was das Wochenende im Urlaub.

Einen Update-Service werde ich nicht programmieren/installieren. Update-Dienste halte ich nur bei Programmen sinnvoll, die weit verbreitet und beliebte Angriffsziele sind, z.B.: Flash, Java, Browser etc.

Ich habe mich entschieden, die Updates über einen Installer auszurollen. Bei Programmstart wird die aktuell installierte Version über eine Datei ausgelesen, mit dem Server verglichen und das dazugehörige Update heruntergeladen. Die Installationsdatei wird geöffnet und erledigt die notwendige Logik. Der Updater ist also - wie vorgeschlagen - "dumm". Um Manipulationen zu verhindern, wird das jeweilige Programm die Hashes in zufälligem Intervall vergleichen. Dabei soll dies keine Umsetzung eines Kopierschutzes sein.

Im Vergleich zu meiner bisherigen Lösung sollte diese nun viel leichter zu verwalten sein. Zwar war die Prüfung pro Datei eine funktionierende Lösung, aber wirklich umständlich zu benutzen.

Demnach wird es demnächst so von statten gehen:

1. Programmiererzeugnisse und Abhängigkeiten in den Release-Ordner verschieben (wenn nicht bereits getan)
2. Rollout erzeugen (zB: via InnoSetup)
3. via Oberfläche eine update.ini erzeugen und automatisch veröffentlichen lassen
4. Benutzer startet sein Programm
5. Updater vergleicht remote-Versionskennung (aus updates.ini) mit lokaler Versionskennung aus Datei/DB. (Versionskennung könnte Build-nr, timestamp etc. sein)
6. Wenn sich diese unterscheiden, läd der Updater das Rollout herunter (Datei entimmt er der updates.ini)
7. Nach dem Download wird das Rollout mittels Hash verifiziert.
8. Das Rollout wird installiert bzw. Daten werden entpackt (je nachdem ob portable oder fest installiert)
9. Programm wird wieder gestartet.

Habe ich etwas wichtiges vergessen oder nicht bedacht? Das müsste doch eigentlich so in Ordnung und dennoch recht flexibel sein, oder?

Danke!

[Dejan Vu]

Gibts da nix Fertiges? Wenn nicht, wäre das nicht mal ne Idee?

[TheMiller]

Ich habe schon mal was fertiges gesehen, aber ich glaube, das kostet Geld. Ich programmiere das mal soweit fertig, wenn Interesse besteht kann ich es ja vllt. teilen.

[generic]

Zitat von Dejan Vu:

Gibts da nix Fertiges? Wenn nicht, wäre das nicht mal ne Idee?

Einen universellen Updater gab es mal von InstallShield. Der konnte auch mehrere Programme mit Updates versorgen.
http://consumer.installshield.com/work_um.asp

Das Windows Update lässt sich auch übrigens erweitern, allerdings kann ich nicht sagen ob das wirklich für eigne Updates taugen wird (ohne Domäne).

[FBrust]

Hallo,

Zitat von DJ-SPM:

1. Programmiererzeugnisse und Abhängigkeiten in den Release-Ordner verschieben (wenn nicht bereits getan)
2. Rollout erzeugen (zB: via InnoSetup)
3. via Oberfläche eine update.ini erzeugen und automatisch veröffentlichen lassen
4. Benutzer startet sein Programm
5. Updater vergleicht remote-Versionskennung (aus updates.ini) mit lokaler Versionskennung aus Datei/DB. (Versionskennung könnte Build-nr, timestamp etc. sein)
6. Wenn sich diese unterscheiden, läd der Updater das Rollout herunter (Datei entimmt er der updates.ini)
7. Nach dem Download wird das Rollout mittels Hash verifiziert.
8. Das Rollout wird installiert bzw. Daten werden entpackt (je nachdem ob portable oder fest installiert)
9. Programm wird wieder gestartet.

Ich mache es derzeit genauso (allerdings ohne Hash, aber diese Anregung nehme ich gerne mit). Ich habe mir einen "Uploader" geschrieben, der aufgrund der Programmversion im Release-Ordner die update.ini erzeugt und Setup-Programm und ini-Datei auf einen Server hochlädt.

Unterscheidungsmerkmal ist dabei die Build-Nummer, d. h. bei jeder Programmversion, die veröffentlicht wird, muss zwingend die Buildnummer erhöht werden.

Setups werden auch mit Innosetup erzeugt.

Das Programm startet nach dem Herunterladen das Setup im Silent-Modus, d. h. das Setup läuft zwar sichtbar, aber ohne Eingriffsmöglichkeit (ist ja nur ein Update) durch und startet danach das Programm wieder.

Das alles läuft seit ca. 5 Jahren ohne Probleme.

Gruß
Frank

[Sir Rufo]

Zitat von FBrust:

Unterscheidungsmerkmal ist dabei die Build-Nummer, d. h. bei jeder Programmversion, die veröffentlicht wird, muss zwingend die Buildnummer erhöht werden.

Genau da halte ich mich eher an die hier beschriebene Vorgehensweise.
Die Auslieferung erhöht die Hauptversions-, Nebenversions- oder Revisions-Nummer.

Die Buildnummer ist hier eher unwichtig. Zur Auslieferung wird dann im VCS auch ein entsprechendes Tag gesetzt (1.0.0, 1.0.1, 1.1.0, ...)

[FBrust]

Hallo,

@Thomas K: Ich hatte keinen roten Kasten.

Ansonsten verwende ich auch nur eine Setup.exe die nach Bedarf mit Parametern aufgerufen wird.


Gruß
Frank

[Thomas_K]

Zitat von FBrust:

Hallo,
@Thomas K: Ich hatte keinen roten Kasten.
Frank

Aber ich und ich wollte/konnte auch nix mehr Ändern bzw. Bezug auf deine Antwort nehmen - sorry.

[Thomas_K]

@Frank "Zwischenzeitlich sind neue Beiträge geschrieben worden."

So grob wie das DJ-SPM hier beschreibt hab ich das hier am Laufen - nur erstmal nur im Intranet. Ach ich verwende innosetup für die "donkey work".

Ich verzichte/vereinfache ein paar Dinge. Es gibt bei mir kein einständiges Update-Hilfs-Programm, sondern der Update.ini check machen die Programme selbst, in einem extra Threads (Objekt Orientiert). Innosetup führt schon eine Integritätsüberprüfung selbständig durch, schlecht ist aber auch nicht das nochmal zu kontrollieren. Es besitzt ein silent bzw. ein verysilent Installations-Modus, von dem ich regen Gebrauch mache (Parameter stehen in den Update.ini(s)) , außerdem lassen sich weitere Kommandozeilenparameter auswerten, die am Ende des automatischen Setups das Programm wieder selbständig starten lässt, zusammen mit einem Kommandozeilenparameter (‚/update‘), der wiederum dafür sorgt, dass eine Erfolgsmeldung angezeigt wird, die der Anwender nur noch ab nicken brauch. Der Vorgang dauert im Allgemeinen hier nur wenige Sekunden.

Es gibt auch keine Zwei verschiedene Setup.exe(s) sondern update - und reguläres Setup ist ein und dieselbe Datei. Mit Innosetup brauch man auch nicht unbedingt in das Programm-Files, sondern automatisch unter appdata installieren, wenn der Anwender eh keine Admin-Rechte besitz, so brauch man auch niemanden bei jedem Update zu Bitten und Betteln.