![]() |
AW: Programm aktualisieren (Codehilfe)
Zitat:
Nicht, dass das nicht auch so gehen würde, aber bei jedem Release muss man höllisch aufpassen, dass dieser Update-Code funktioniert. Und wofür? Weil der Code genau einmal zum Einsatz kommt? Dann doch lieber einen Updater der einmal gebaut und (bei jedem Update) immer wieder benutzt werden kann. Kleines Beispiel: Ändert sich z.B. der Mutex-Name (erkennen ob die alte Anwendung noch läuft), dann muss die neue Anwendung alle alten Mutex-Namen kennen sonst knallt es. Der Updater bekommt von der aktuellen Anwendung den Mutex-Namen mitgeteilt und kümmert sich entsprechend. Bevor mir jetzt einer kommt "Ich benutze keinen Mutex" oder "Mein Mutex ändert sich nicht" - es ist nur ein Beispiel was mir jetzt adhoc mal eingefallen ist und aufzeigen soll, dass kleine Änderungen einen Rattenschwanz hinter sich herziehen können, die durch einen externen Updater wesentlich eleganter und einfacher gelöst werden können. |
AW: Programm aktualisieren (Codehilfe)
Executables werden vom Windows ja wiederverwendet.
Das kennt man z.B. von DLLs, wo ja viele Programme die selben DLLs benutzten und es demnach natürlich praktisch ist, wenn die DLL dann nur einmal im physischem RAM liegt und dann nur noch bei all den Programmen in den virtuellen Arbeitsspeicher gemappt wird. Und auf Seiten vom Windows sind EXE und DLL genau das Selbe. Ach ja, dank Copy-On-Write stört es dann natürlich nicht, wenn Programme ihren Code patchen, da es nur auf die eigene DLL einen Einfluß hat und nicht auf alle Programme. Nur ist natürlich nirgendwo dokumentiert wie Windows erkennt, ob es sich um die selbe EXE/DLL handelt, was man z.B. auch ganz einfach anhand des Dateinamens bestimmen könnte. :stupid: Und das Wann es eventuell nicht geht ... da kann es viele Gründe geben - das Dateisystem - Dateisystemtreiber - Virenscanner und Co. - andere Dateizugriffe - Netzlaufwerke - ... - und letztendlich kommt das alles irgendwie darauf an WIE die Datei geöffnet ist. Und dann ist es nunmal kein offiziell dokumentiertes und festgelegtes Verhalten, was sich somit irgendwann auch wieder ändern könnte. Billigstes Beispiel:
Delphi-Quellcode:
procedure TForm23.FormCreate(Sender: TObject);
begin TFileStream.Create(Application.ExeName, fmOpenRead or fmShareDenyNone); end; PS: Normaler Weise hat (sollte) ein einfaches "Benutzer"-Programm keine Rechte besitzen, um einfach so irgendwelche Programme zu ändern. (siehe Programme-Verzeichnis) |
AW: Programm aktualisieren (Codehilfe)
Zitat:
Und es ist ja nicht so, dass das Raketenwissenschaft ist. Du musst halt nur deinen Updater-Code, den du schon in deiner Form1 mitschleppst, in eine externe Anwendung auslagern und dich dann nur noch um den korrekten Ablauf kümmern (also Updater mit erhöhten Rechten (Adminrechten) starten, Hauptprogramm schließen, Update durchführen, Hauptprogramm neu starten (nur mit User-Rechten)). |
AW: Programm aktualisieren (Codehilfe)
Man kann ja problemlos das Update im Hintergrund mit dem Programm runterladen und validieren. (machen viele Programme)
Aber das Installieren/Kopieren sollte etwas Anderes machen. Das kann aber auch ein Script sein ... Batch (bat), Commandfile (cmd), PowerShell (ps), ... |
AW: Programm aktualisieren (Codehilfe)
Nur als Anregung :wink:
Mein upzudatendes Hauptprogramm (chef.exe) übergibt meiner updater.exe zwei Parameter: "Pfad zu chef.exe" und die interne Versionsnummer von chef.exe als String (z.B. "20131224" für letztes Jahr Weihnachten) Updater.exe beendet chef.exe und ermittelt aus dem Pfad die URL für den Download des Updates und die URL für die aktuelle Versionsnummer: ![]() ![]() Der Inhalt von chef.txt wird mit dem zweiten Parameter verglichen und - je nach Ergebnis das Update heruntergeladen - chef.exe wieder gestartet. Mit Delphi 7 PE und den Indies (IdHTTP unter Win 8.11 Pro) kein Hexenwerk, da Windows für updater.exe (aufgrund des Echsennamens) automatisch höhere Rechte einfordert. Bei meinen Updates geht es immer um mehrere Dateien, die aktualisiert werden müssen, daher lädt mein updater.exe ZIP-Dateien herunter und entpackt sie anschließend in den Pfad von chef.exe. TZip: ![]() Allerdings hat mein chef.exe nichts mit Datenbanken zu tun - wie auch, mit Delphi 7 PE :cry: MfG |
AW: Programm aktualisieren (Codehilfe)
Delphi konnte doch schon immer mit Datenbanken umgehen? :roll:
Dank Fremdkomponenten auch in kleineren Versionen. Zitat:
Und wenn es das tut, dann aus einem Grund: "Ohh, das ist ein Schrottprogramm, welches sich nicht an über 7 Jahre alte Regeln hält ... ich vermute mal, es ist ein Setup-Programm und gebe ihm, wenn ich Lust hab, vielleicht Adminrechte" (solange keiner auf die Idee kommt und diese Mustererkennung deaktiviert :roll:) Langsam sollte man mal davon ausgehen, daß Programmierer endlich wissen was sie tun. Und wenn es nach mir ginge, würde solche Mustererkennung langsam mal wieder ausgebaut. :twisted: |
AW: Programm aktualisieren (Codehilfe)
Danke für eure Antworten und hilfen.
Ich habe mich nun doch dazu entschieden das problem mithilfe der update.exe zu lösen und es funktioniert alles bestens. Lg Simon |
Alle Zeitangaben in WEZ +1. Es ist jetzt 02:20 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz