Hallo!

Nach den SJ Config Utils zur Konfiguration von eigenen Projekten stelle ich dieses Projekt vor, mit dem man die eigene Anwendung einfach aktualisieren kann. Ohne zusätzliche Exe und mit korrekter Umsetzung mit der UAC unter Vista / 7.

Wichtig:
Sicherheitsmerkmale sind noch nicht vorhanden. Die downgeloadeten Updates werden also noch nicht geprüft!

Features:

• Direkte Integration in die Exe ohne zusätzliche DLLs oder Exe-Dateien.
  
• Anzeige des UAC-Prompts unter Vista
  
• Fortschrittsanzeige (noch nicht ganz flüssig)
  
• Demo-Projekt inkl. Update-Demo auf meinem Server
  
• Versionsangabe, damit Dateien nur bei Bedarf geladen werden

Lizenz:
MPL 1.1 oder LGPL 2.1 oder GPL 2.0 (oder höher)

Installation und Verwendung:
Die Zip-Datei auspacken und die Units dem Projekt hinzufügen. Dann die AppGuid in der Unit SJUpdaterUtils.pas ändern und die unter "Formatdefinitionen - Dateiliste online" beschriebene Updatedatei erstellen und hochladen, zusätzlich eine Datei mit der aktuellen Versionsnummer.

Dann muss nur noch wie im Demoprojekt eine Instanz der Klasse TSJAutoUpdater erstellt werden und die Eigenschaften zugewiesen werden. CheckForNewVersion prüft auf eine neue Version, StartUpdate startet dann das Update.

Meine Beispieldateien für die Demo sehen so aus (zum Test einfach einmal z.B. die Readme.txt löschen):

filelist hat folgendes geschrieben:

update;www.sj-berlin.de/upd...e;SJUpdUtilsDemo.exe update;www.sj-berlin.de/upd...eadme.txt;Readme.txt

versioninfo hat folgendes geschrieben:

1.6

Getestete Delphiversionen:
Delphi 2006 / Turbo Delphi, Delphi 2007 (andere Versionen funktionieren derzeit definitiv nicht!)
Indy 10 wird benötigt!

Getestete Windowsversionen:
2000, XP, Vista, 7
Windows 9x/ME wird definitiv nicht unterstützt. Der Aufwand aufgrund der unterschiedlichen Architektur wäre zu groß.

Bekannte Probleme:

• Es werden kaum Fehlerprüfungen und keine Sicherheitsprüfungen durchgeführt!

Das Projekt habe ich auch hier vorgestellt:
www.delphipraxis.net/post1071944.html
forum.delphi-treff.d...wthread.php?p=198233

Schönen Gruß,
Sebastian

Kurze Frage dazu. Ist es auch möglich, bei mehreren Updateschritten nur die Dateien zu übertragen, die wirklich benötigt werden? Beispiel: Unsere Anwendung besteht im großen und ganzen aus folgenden Teilen: Die EXE, einige Reports und SQL-Scripte, sowie einige DLL-Dateien.
Die EXE ändert sich bei jedem Update
Die Reports und Scripte ändern sich manchmal, aber nicht immer. Es kommen auch mal neue hinzu.
Die DLLs ändern sich praktisch nie.

Nun muss natürlich ein User, der ein Update von Version 1 auf Version 5 macht mehr Dateien runterladen, als ein User, der nur ein Update von Version 4 auf 5 macht. Unterscheidet dies Dein Tool?

Gruß,
Jens

Im Moment nicht, aber es ist ja kein großes Problem für jede Datei noch eine Versionsnummer hinzuzufügen. Dann kann man diese einfach vor dem Update vergleichen.

Ich bin mir da nur noch nicht im Klaren wie das sinnvoll zu lösen geht. Bei Exe-Dateien oder DLLs, kein Problem, die haben eine Versionsnummer. Aber bei anderen Dateien würde es schwieriger. Deshalb werde ich es für DLLs und Echsen relativ schnell einbauen, bei anderen mal schauen, wie das sinnvoll in Abhängigkeit von der Version z.B. der Exe lösbar ist. Das muss ich mir noch genauer überlegen, auch was die Zeiteinteilung der Projekte angeht.

Insbesondere werde ich da ein richtiges Dateiformat (XML z.B.) statt dem jetzigen unübersichtlichen Textformat einbauen, so dass man da auch mehr einstellen kann.

Meine Überlegung wäre, dass man ja nur speichern müsste, in welcher Programmversion jede Datei das letzte Mal geändert wurde. Z.B. in der angedachten XML-Datei. Nun kann der Updater schauen, welche Programmversion lokal vorliegt. Dann läd er die XML-Datei runter und schaut, bei welchen Dateien die Version > der lokalen Version ist und läd nur diese Dateien runter.
Für mich wird vermutlich zum Winter so etwas für unsere Anwendungen anstehen. Und da kommt jetzt bei mir die Überlegung auf, ob ich es selbst schreibe, oder evtl. auf Deine Arbeit aufbaue. Aber die Entscheidung hat noch etwas Zeit.

Gruß,
Jens

Ich werde mir da einmal etwas überlegen. Das Problem ist, dass man dann jeder Datei eine eigene Versionsnummer geben müsste. Bzw. eine automatische Revisionsänderung wie auch hier im Forum bei Downloads bei einer Änderung. Wäre denn bei dir eine der beiden Möglichkeiten praktikabel? Also entweder manuell jeder Datei eine Version zuweisen oder in einem bestimmten Verzeichnis einen Vergleich an Hand der Hashes automatisch durchzuführen um ein neues Update zu erstellen.

Grundsätzlich ist es natürlich so, dass noch Hashes usw. ohnehin eingebaut werden, so dass man diese auch zur Versionsidentifikation nutzen kann.

Eine andere Frage ist natürlich, ob bei solchen ja vermutlich größeren Projekten ein externer Updater nicht besser wäre. Denn das wäre natürlich einfacher, weil da nicht so viel IPC notwendig wäre wie bei diesem integrierten Updater. Oder je nach Updatefrequenz und Zielgruppe vielleicht auch ein Dienst, der im Hintergrund läuft, damit keine Adminrechte angefordert werden müssen (falls es für Firmen gedacht ist, wo das wichtig wäre).

Nö, warum müsste man denn dann den Dateien Versionsnummern geben?
Man speichert nur in der Textdatei (oder XML, egal), in welcher Version die Datei das letzte mal geändert wurde. Ok, das ist eine Versionsnummer, hast Recht

Beispiel:
Datei1 letzte Änderung Version 3
Datei2 letzte Änderung Version 2
Datei3 letzte Änderung Version 2
Datei4 letzte Änderung Version 4

Der Update holt nun erst mal nur die Textdatei. Dann schaut er, welche Version vom Programm lokal vorliegt.
Fall 1: Lokal liegt Version 2 vor. Also sucht er alle Dateien, die > Version 2 sind. In dem Fall Datei1 und Datei4.
Fall 2: Lokal liegt Version 1 vor: Größer als Version 1 sind alle Dateien, also Datei1 bis Datei4
Fall 3: Lokal liegt Version 4 vor: Keine Dateien sind größer Version 4 -> Programm ist aktuell
So werden immer nur die Dateien runtergeladen, die der User wirklich braucht.

Dass die Versionsinformationen nur in den Textdatei gehalten werden hat den Charme, dass es mit allen Dateitypen funktioniert. Was natürlich NICHT geht, ist, ein Update auf Version 3 zu machen, obwohl Version 4 aktuell wäre. Aber wer will das schon. Dieses Vorgehen ist für uns praktikabel. Und falls ich es selbst machen muss, werde ich es vermutlich so machen. Natürlich wäre dafür eine kleines Hilfstool praktisch, das ich bei jeder Fertigstellung mit den geänderten Dateien füttere und das mir eine neue XML-Datei erstellt und den Krams hochläd.

Ein Dienst im Hintergrund ist für uns nicht nötig, es wäre sogar meiner Meinung nach unnötiger Ballast. So oft gibt es keine Updates. Im Schnitt machen wir während unserer Hauptsaison alle 2 Wochen ein Update, wobei nicht alle Kunden die Updates dann einspielen, weil es vielleicht nur Programmteile betrifft, die sie überhaupt nicht benutzen, oder wofür sie nicht mal eine Freischaltung haben. Außerhalb unserer Hauptsaison gibt es die Updates sporadischer und es gibt ein Jahresupdate, das wir auf CD versenden. Das wäre der Punkt, wo ich den Autoupdater einführen möchte. Den Updater in ein externes Programm zu packen kann man machen. Muss man nicht machen. Wäre mir persönlich egal.

Ein Punkt wäre für mich aber noch wichtig. Es müssten Unterordner unterstützt werden. Bei unsere Installationen liegen z.B. die Reports im Unterordner "Reports". Der Updater muss also die neuen Dateien in den richtigen Unterordner kopieren.

Jens

Nersgatt hat folgendes geschrieben :

Nö, warum müsste man denn dann den Dateien Versionsnummern geben? Man speichert nur in der Textdatei (oder XML, egal), in welcher Version die Datei das letzte mal geändert wurde.

Ok, stimmt. Das werde ich einmal einbauen.

Nersgatt hat folgendes geschrieben :

Ein Punkt wäre für mich aber noch wichtig. Es müssten Unterordner unterstützt werden.

Das ist bereits der Fall, man kann auch explizit Ordner anlegen oder löschen, wenn sich daran etwas ändert.

Es gibt eine neue Version, ich habe das wie versprochen eingebaut.

Neuerungen:

• Windows 2000 und XP werden auch voll unterstützt.
  
• Die Meldungen während des Updates können angepasst werden
  
• Die Anwendungsspezifische Guid funktioniert jetzt auch, wenn die Units zentral für mehrere Projekte verwendet werden
  
• Unterstützung von Delphi 2007 wurde erfolgreich getestet
  
• Durch eine Versionsangabe kann man jetzt erreichen, dass Dateien nur dann erneut geladen werden, wenn diese sich seit der installierten Version geändert haben (Idee von Nersgatt)
  
• Das Anlegen und Löschen von Ordnern funktioniert jetzt korrekt

Ach ja: Und nebenbei habe ich Redundanzen entfernt und den Code etwas überarbeitet und übersichtlicher gestaltet. Zudem habe ich den Code besser kommentiert.

jaenicke hat folgendes geschrieben :

Windows 2000 und XP werden auch voll unterstützt.

Was meinst du damit denn genau?

Bei der ersten Alphaversion kam unter XP einfach nur "Zugriff verweigert", egal ob als Admin oder nicht.

Jetzt klappt es auch dort, dass Adminrechte angefordert werden usw.

Moin,

ich habe jetzt mal Zeit gefunden, mir das Projekt anzuschauen. Sieht erst mal ganz gut aus. Ich denke, ich werde noch ein paar Sicherheitsprüfungen einbauen (und die geänderten Versionen dann natürlich hier veröffentlichen).
Mir fehlen halt solche Checks, wenn z.B. die versioninfo-Datei gar nicht auf dem Server liegt, oder der Server nicht erreichbar ist, usw.

Hast Du mal versucht, ob man durch Angabe von Pfaden in der Form "..\..\..\explorer.exe" evtl. aus dem Rootverzeichnis der Anwendung ausbrechen kann und Dateien von anderen Programmen überschreiben? Ich denke, ich werde hier noch eine Prüfung einbauen, die die Verwendung von ".." in den Pfadangaben einfach verbietet und eine Exception wirft. Denn mir fällt kein "nicht bösartiger" Fall ein, in dem man ".." verwenden wollen würde.
Dann werde ich evtl. noch eine Prüfung einbauen, dass die Updatedateien in einem Unterordner relativ zur filelist und versioninfo liegen müssen. Jetzt im Moment würde es reichen, irgendwie in den Server einzubrechen und in der filelist einen Eintrag in der form update;http://sehrBöserServer.böse/bösedatei.exe;bösedatei.exe zu erstellen. Und schwupps läd der Updater böse Dateien aus Fernost nach.

Ansonsten ist es aber schon dass, was ich mir vorgestellt habe. Gute Arbeit!

Gruß,
Jens

Würde der Updater mit einem entsprechenden, asymmetrischen Verfahren arbeiten, würde sowas auffallen, da deine manipulierte Liste keine gültige Signatur mehr hätte.

Zudem sollte man eh die heruntergeladenen Dateien mit signiren.

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

Das würde ich auch gerne einbauen, habe aber bisher noch nichts mit solchen Sicherheitsvorkehrungen gemacht. Deshalb hatte ich bisher nicht die Zeit dazu mir anzuschauen wie sowas eigentlich korrekt umgesetzt wird.

Denn wenn ich da irgendwas implementiere bringts auch nicht viel. Außer zumindest eine gewisse Integritätsprüfung zu haben.

Moin,

ich habe mich nun entschlossen, dein Projekt nicht einzusetzen. Ich habe selbst einen Updater programmiert. Ich möchte auch kurz auf die Gründe eingehen.

- Mir gefällt das Konzept nicht, dass sich die Anwendung ständig selbst neu startet mit verschiedenen Parametern. Da ich einen eingenständigen Updater brauche, der auch Programme, die in anderen Sprachen geschrieben sind (z.B. VB.NET), updaten kann, kann ich den Updater gleich Adminrechte anfordern lassen (über ein entsprechendes Manifest). Das macht die ganze Sache ungleich einfacher.

- Dein Updater geht davon aus, dass es in einem Projekt nur eine EXE-Datei gibt, die auch Updater-Funktionalität beinhaltet (vgl. setzen der Variable FMainExecutable). Mein Projekt besteht zur Zeit aus 10 EXE-Dateien. Hier müsste ich die Arbeitsweise Deines Updater ändern, damit das mit meinem Projekt zusammenarbeitet

- Dein Updater soll ja in die Anwendung integriert werden. Dabei startet der Updater die Anwendung mehrfach mit verschiedenen Parametern neu. Der Updater geht davon aus, dass die Anwendung selbst keine Parameter verwendet. Meine Anwendung kann schon jetzt mit verschiedenen Parametern gestartet werden, die verschiedene Dinge in der Anwendung auslösen. Die Parameter des Updaters in meine Anwendung zu integrieren wäre in nicht unerheblicher Aufwand.

- Mir fehlen einige Funktionen. Z.B. möchte man doch dem User anzeigen, welche Version im Internet verfügbar ist. Lässt sich natürlich einbauen, aber das sauber in Dein Programmkonzept zu integrieren ist auch Aufwand.

- Einige kleine Bugs sind wohl auch noch drin. VerToInt ignoriert z.B. das letzte Zeichen des Versionstrings. Dies muss man alles debuggen und korrigieren. Du wirst mir sicher zustimmen, dass es einfacher ist, eigenen Code zu debuggen. Bei fremden Code muss man sich erst reindenken, was sich der Programmierer dabei gedacht hat.

Alles in allem bin ich zu dem Schluss gekommen, dass ich schneller meinen Updater genau so bekomme, wie ich ihn möchte/brauche, wenn ich es komplett selbst schreibe, was ich nun auch getan habe.
Mein Updater setzt auf folgende Konzept
- Eigenständiger Updater
- Fordert beim Start Adminrechte an
- Download der Dateien in einem Temp-Ordner, dann die Dateien installieren, temp-Dateien löschen.
- Der Updater erstellt beim Programmstart einen Mutex. Damit wird verhindert, dass die Hauptanwendung gestartet wird, während der Updater aktiv ist. Außerdem wird verhindert, dass der Updater 2x gleichzeitig läuft. Wäre in Deiner Version komplizierter implementierbar, weil sich die Anwendung selbst neu starten können muss.
- In der Dateiliste (filelist) wird er Pfad zu den Remotedateien relativ zur filelist angegeben. Das verhindert, dass Dateien von anderen Servern geladen werden. Außerdem ist es so einfach möglich, den Pfad zu dem ganzen Updatekrams auf dem Server zu ändern, in dem man die Dateien einfach verschiebt. Bei Deiner Version müsste man die Pfade in der filelist anpassen.

Bitte nicht falsch verstehen, Deine Arbeit ist sicherlich für einfache Projekte gut, aber für meine Zwecke einfach nicht das Richtige. Ich möchte Deine Arbeit mit diesem Posting auch nicht schlecht reden, sondern nur einige Punkte aufzeigen, an die man denken muss/kann, bzw. die man besser machen könnte.

Gruß,
Jens

Hallo Jens,

so einen Updater, wie Du ihn beschreibst habe ich mir schon vor Jahren gebastelt.
ABER beide Ansätze haben ihre Berechtigung.
Manchmal will man ja wirklich nur die eine Exe updaten, dann ist so ein eigenständiger Updater je nach dem wie komfortabel er ausgebaut ist, schon ein wenig überdimensioniert.

Wie gesagt, BEIDES hat seine Berechtigung !

Gruss
Michael

Hi Sebastian,

ich habe gerade deinen SJ-Updater getestet.
Die Demo-Version zum Herunterladen unter www.sj-berlin.de/upd...o/SJUpdUtilsDemo.exe
scheint viel flüssiger zu laufen, als die im Source-Code (z.B. ProgressBar).

Ausserdem bleiben bei der compilierten Version drei Fenster nachdem Update offen. (Das Fenster des alten Programms, des neuen Programms und der Meldung "Das Update wurde erfolgreich beendet")
Bei deiner Version auf der Homepage nicht. Hast Du deinen Code weiterentwickelt?

Wäre nett wenn du hier den aktuellen Code posten könntest.

Gruss und Danke im vorraus Alois

Ich habe die neue Version noch kurz überarbeitet und hochgeladen. Leider passten die Versionen nicht zusammen, deshalb die Fehler beim Update.
Ich hatte im Zuge eines anderen Projekts an dem Updater gearbeitet und dabei vergessen auch dieses Projekt zu aktualisieren.

Ja, was ist neu: Es läuft alles ein wenig flüssiger und es werden nicht mehr unnötige Fenster angezeigt.
Zwei Probleme gibt es noch:
Erstens hängt das Programm, wenn die Internetverbindung schlecht ist und beim Update abbricht.
Zweitens werden Textdateien nicht "as-is" heruntergeladen sondern kommen (bei meinem Server) mit UNIX-Zeilenumbrüchen an.
Erledigt, das war nur ein Problem beim automatischen Upload.

Ich plane allerdings ohnehin gepackte Updatedateien zu verwenden, das erschlägt dann gleich mehrere Probleme (CRC-Check + kleinere Dateien). Wann ich dazu komme weiß ich allerdings noch nicht.

Hi Sebastian,

vielen Dank für die schnelle Antwort. Werde die neue Version gleich mal testen.

Gruss Alois

Ich arbeite auch gerade noch daran, vielleicht schaffe ich es in den nächsten Stunden noch weiterzukommen was die geplanten Features oder die beiden das Problem angeht.
Diesmal werde ich aber die Onlineversion nicht mehr durcheinander bringen.

Wenn ich das Programm kompiliere (D2010) und starte erhalte ich nach der Meldung "Das Update wurde efolgreich beendet!" immer einen EAccessViolation.
Anscheinend beim Schliessen des alten Programms.

In Deiner DEMO (vorkompilierten Exe) passiert das nicht.