Prüfmethoden für Updates

[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

[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.

[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.

[FBrust]

Hallo,

Zitat von Thomas_K:

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

Ach so, dann ist ja gut

Gruß
Frank

[TheMiller]

So, mein Updater ist nun fertig. Ich werde ihn noch etwas testen und dann - wenn Interesse besteht - mit euch teilen. Ich habe eine Demo-Applikation geschrieben, ein RolloutMaker zum Erstellen von Updates und alles ist via DoxyGen dokumentiert.

Der Updater, bestehend auf 4 Klassen, kann derzeit folgendes:

• Simple Einrichtung: Die Update-Suche und das Downloaden ist in 10 Codezeilen durch Benutzung der Update-Klasse vollständig konfiguriert.
• Simples Erstellen von Rollouts: Mit 3 Klicks ist das Rollout erstellt und veröffentlicht.
• Automatisches Erstellen der lokalen Versionsdatei, welche zum Vergleich dient.
• Automatische Suche nach Updates. Versionserkennung anhand einer (selbstdefinierbaren) Versionsnummer. Sie muss nicht einkompiliert sein.
• Updates herunterladen (eigener Thread). Indy-Events OnWork etc.pp. werden durchgereicht, sodass die Stati und Fortschritte in der GUI anzeigbar sind.
• ReleaseNotes publizieren und anzeigen.
• Erstellen eines Updates: 3-Klick-System. Der RolloutMaker läd das Projekt, liest die neuen Infos aus, erstellt die Steuerdatei und lädt die Daten automatisch per FTP an ihren Platz (eigener Thread). Auch hier werden alle Events durchgereicht. Die FTP-Einstellungen werden in den Projekteinstellungen definiert.
• Durch den Aufbau des Updaters und der lokalen Versionsdatei ist es möglich, ein zentrales Update-Programm für mehrere eigene Produkte zu erstellen.

Das waren jetzt alle Highlights, glaube ich. Klar kann man immer etwas verändern, aber so funktioniert es erstmal. Bei Interesse lade ich es gerne mal hoch.

Auf diesem Wege möchte ich damit erstmal für die Hilfe, Anregungen und Ideen bedanken.

[Dejan Vu]

Ersetzt Du die Dateien direkt? Was passiert beim Verbindungsabbruch? Funktioniert dann alles noch?
Oder war das nur missverständlich formuliert?

Zitat:

...und lädt die Daten automatisch per FTP an ihren Platz (eigener Thread).

[sh17]

Um noch einmal den Streitpunkt "Update als Service" aufzugreifen:

Welche Möglichkeit gibt es denn noch, es dem Benutzer einer Anwendung so einfach wie möglich zu machen?

Als Beispiel, meine Anwendung besteht aus einem Service, der irgendwo auf einem Server rumdümpelt.
Der hat manchmal nicht mal einen gescheiten Monitor, geschweige denn kommt da jeder Anwender ran.

Meine Idee ist nun, einen zweiten Update-Service daneben zu installieren, der den Hauptdienst überwacht
,ggf beendet und aktualisiert. (Meinetwegen auch per anstubsen vom Benutzer) Mit dem Update werden noch
die Client-Pakette bereitgelegt, die sich dann die Clients beim nächsten Anmelden über einen Starter
vom Server herunterladen und installieren. So hab ich doch ein recht gutes System, was sich selbst
verteilt und sehr wenig Eingriffe vom Benutzer benötigt. Die haben nämlich in der Regel keinen Admin
an der Seite.

Ich würde sogar noch soweit gehen, das der Updater von uns als Anbieter ferngesteuert werden kann, wenn der
Kunde das möchte (in der Regel stimmen sie zu, sie wollen so wenig wie möglich machen,
außer einfach die Software verwenden). Mit noch ein paar kleinen Tests könnte man die Installation
noch auf Fehler prüfen und wir können eingreifen.

Aber wenn wer noch eine andere Idee hat, ich bin interessiert.

[Barthiboy]

Hallo,
ich würde Interesse an dem Updater anmelden.
Gibt es irgendwo ein Repository oder einen Link, wo ich ihn herunterladen kann?
Danke

Gruß
Christian

Das waren jetzt alle Highlights, glaube ich. Klar kann man immer etwas verändern, aber so funktioniert es erstmal. Bei Interesse lade ich es gerne mal hoch.

Auf diesem Wege möchte ich damit erstmal für die Hilfe, Anregungen und Ideen bedanken.[/QUOTE]