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