Inoffizielles deutsches Xbase-Forum

Hallo Kollegen,
ich möchte meinen Kunden Updates per Webseite/Dwonload zur Verfügung stellen. Wie könnte ein solches Vorgehen aussehen?

Wie müßte das Update aufgebaut sein?

Wenn du deine EXE einfach ersetzen willst, kannst du eine EXE downloaden und entpacken (ZIP), wenn du Installer hast, dann lädst du den.

Ich habe damals für meine Tante so ein System zusammen gestellt, aber da war beides klar und keine Kosten / Lizenzen im Weg.

Auf einer Website habe ich eine Textdatei hinterlegt, die die Version der neuesten EXE und DLL enthielt.
Die Anwendung selbst hat dort (mit LoadFromURL) die Datei abgeholt. Bei Änderungen wurde eine Meldung angezeigt, dass es neue Versionen gibt.
Da ich ja nur EXE und DLL getauscht habe, habe ich auf Wunsch eine andere EXE aufgerufen, die die Datei geladen und entpackt hat.
Dieses "Updateprogramm" muss in einem anderen Verzeichnis mit eigener Runtime sein, sonst kann man die anderen nicht überschreiben.
Entpacken, und Dateien ersetzen, Programm beenden. Beim nächsten Start muss die neue EXE noch prüfen ob DBF Strukturänderungen nötig sind und die erledigen.
Auf der WWW Seite habe ich einfach ein Unterverzeichnis genutzt, auf das man normal nicht kommt.

Vielen Dank! So ähnlich habe ich mir das schon gedacht, aber keine Erfahrung damit.

Hallo Wolfgang

ich mache das schon länger. Das Update erstelle ich mit Inno-setup. daraus eintsteht ein exe-file . diese lade ich mit file Zilla auf meine Domain hoch

den entsprechenden Link habe ich in meine Homepage eingebaut.

ist nicht schwer

Rolf, vielen Dank. Schau ich mir an.

Lässt sich auch relativ einfach automatisieren.

Mein Programm prüft in frei wählbarem Abstand (bei jedem Start/Woche/Monat) ob ein Update verfügbar ist. Dazu wird kurz eine FTP-Verbindung zu meinem Server aufgebaut und geschaut ob ein bestimmtes Verzeichnis oder Datei vorhanden ist. Ich habe dafür ein Verzeichnis genommen, dessen Name meine aktuelle Programmversion (z.B. 487) ist. Wenn das Verzeichnis nicht vorhanden ist wird dem User ein Update angeboten - wenn gewünscht wird das per Inno-Setup erstellte Update per FTP heruntergeladen. Nach einem Hinweis wird das laufenden Programm beendet und die Installation des Updates gestartet - ist alles idiotensicher und läast sich ohne Zusatzprogramme mit wenigen Zeilen Code direkt in Xbase machen.

Ich erstelle bei jeder neuen Programmversion automatisch eine Textdatei, in der jede Datei mit ihrer Versionsnummer drin steht (nicht nur meine Programmdateien, sondern auch Tools und die Xbase++-Runtimes). Die lade ich bei Updatekontrollen per FTP herunter, und vergleiche jeden einzelnen Eintrag mit der Version der entsprechenden Datei beim Kunden. Ist die älter, wird die neue Datei ebenfalls per FTP herunter geladen. Früher hab ich das mit LoadFromUrl() gemacht, heute mit FTPClient()

Damit habe ich die Möglichkeit selektiv nur die geänderten Dateien herunter zu laden. Heute ist das vermutlich nicht mehr ganz so wichtig, aber als ich angefangen hatte waren die Leitungen halt noch nicht im 3stelligen MBit-Bereich, meist noch nicht mal im 2stelligen.

Jan

Unsere Software prüft (je nach Einstellung) im Hintergrund, ob der Kunde updateberechtigt ist, indem über die API, die unser CRM (Fremdprodukt) zur Verfügung stellt, ein entsprechender Request abgesetzt wird. Der gleiche Request gibt darüber Auskunft, ob der Kunde über Neuerungen oder bekannte Probleme in seiner Version informiert werden will; wenn das der Fall ist, ergänzt sich die Antwort entsprechend (ein vorformatiertes und automatisch generiertes HTML-Dokument wird mitgesendet, das es für alle Versionen, die noch supportet werden, in aktuellen Fassungen gibt). Hat der Kunde Updateberechtigung, also einen bestehenden und bezahlten Pflegevertrag, prüft die Software über einen weiteren Request an eine webbasierte Datenbank, welche Versionen aktuell freigegeben und stabil sind - wir führen immer zwei Updates, aber nur stabile installieren sich automatisch. Nach Abfrage oder auf Wunsch automatisch wird dann ein verschlüsseltes ZIP geladen, ebenfalls im Hintergrund, und heimlich entpackt. Das wandert dann in ein Verzeichnis auf dem Server. Wenn das alles erfolgreich war, bietet die Software an, sich neu zu starten, um das Update zu installieren, indem eine kleine Xbase-EXE einfach die Dateien vom Server ins lokale Verzeichnis holt. Ansonsten würde sie halt beim nächsten Neustart merken, dass es auf dem Server ein Update gibt - und die gleiche kleine Xbase-EXE, die zur Auslieferung gehört und immer vorhanden ist, würde das automatisch ins lokale Installationsverzeichnis holen. Der Prozess ist äußerst komfortabel und sehr verlässlich.

Kunden können sich aber Updates auch selbst holen. Dafür müssen sie sich im Kundenbereich unserer Website einloggen und das Update (Inno-Setup) ziehen, außerdem generieren sie sich dort einen Freigabeschlüssel, den das Update abfragt (eingebettete DLL). Die Installation erfolgt dann in ein Arbeitsplatzverzeichnis, aus dem die jeweilige Installation das dann zum Server schiebt, wenn sie merkt, dass sie selbst aktueller als das ist, was dort liegt. Die anderen Arbeitsplätze kriegen das dann automatisch beim Programmstart.

Weil ganz, ganz viele Leute aber mit alldem immer noch überfordert sind oder darauf keine Lust haben, installiert unser Support auch Updates direkt bei den Kunden, und nicht bei wenigen.

Wie fängst du dann ab, dass irgendjemand in einem Programm ist und das zum Drüberkopieren gesperrt ist?

Die kleine Drüberkopier-EXE prüft, ob ein aktiver Prozess im betroffenen Verzeichnis unterwegs ist.

Ich kopier die runter geladenen neuen Programmdateien in ein Update-Verzeichnis, bitte den Nutzer das Programm neu zu starten, erkenne beim nächsten Start das es was im Updateverzeichnis gibt, schreibe eine Batch aus dem Programm heraus per FWrite(), beende das Programm direkt wieder, und rufe die Batch auf. Die kopiert die neuen Dateien rüber, und startet dann das Programm mit den aktualisierten Dateien wieder.

Etwas krude, aber es klappt hat ohne viel Aufwand.

Jan

Das ist so ähnlich wie bei uns, Jan, nur mit etwas komplexerer Ansteuerung - und mit Batches arbeiten wir nicht mehr.

Hallo Tom,

ich muß gestehen das ich ziemlich enttäuscht von Dir wäre, wenn Ihr das noch so machen würdet. Das würde nicht mehr wirklich zu Deiner Software passen.

Jan