Update vom eigenem Programm.exe

[Luckner]

Hallo,

da mittlerweile das Tool auf ca. 10 Rechnern (Windows) in unseren Firma läuft und immer wieder erweitert bzw. korrigiert wird, wollte ich mir langsam das manuelle Kopieren und Ersetzen der Programm.exe auf den PC's sparren. Die Laufwege sind schon erheblich und man wird nicht jünger. Habe auf einem Server ein Unterverzeichnis '\Programmupdate\Programm.exe' und diese wird auf allen Pc's kopiert. Jetzt würde ich das mit einer Routine in meinem Tool bewerkstelligen. Es handelt es sich immer um 1 exe-Datei, die dann als Hinweis mit neuem Erstelldatum versehen ist. Mit welchen Delphi-Komponenten könnte ich dieses Kopieren und nach Datum überprüfen der Datei bewältigen? Der Pfad für das Update wäre vorgegeben und der Anwender soll nur 'ja/nein' wählen können. Wobei 'ja' fast ein muß wäre. Wenn eine Exe-Datei gerade im System läuft läßt die sich ohne weiteres ersetzen?

Danke für ein paar Hinweise.

Luckner

[borncrush]

Naja, eigentlich nicht, weil sie ja verwendet wird.

Programmiere doch ein eine extra EXE, die vorher auf Updates prüft und eben die EXE bei Bedarf austauscht.

Der User startet das Vorschaltprogramm....dies prüft auf Updates, wenn ja, updaten, wenn nicht, normale EXE starten.

Quick and Dirty :-)

[nahpets]

Hab' vor Jahren mal sowas mit der Methode "billig" gemacht.

Aus dem Programm wird eine Batchdatei erstellt und diese wird per ShellExecute aufgerufen.

Die Batchdatei könnte (in etwa) so aussehen:

Code:

:REM gibt eine Pause von ca. 4 Sekunden, in der Zeit kann sich das Programm beenden.
ping 127.0.0.1 >nul
:REM Programm kopieren
copy \Programmupdate\Programm.exe Programm.exe
:REM Programm starten
Programm.exe
:REM Die Batchdatei loescht sich selbst
del %0

[BUG]

Mhm, das Thema gab es hier auch schon öfter. Eine andere übliche Lösung war es afaik, dass das alte Programm das neue, heruntergeladene aufruft und sich dann beendet. Das neue Programm löscht das alte und benennt sich um.

[Luckner]

Die Kombination von ShellExecute und Batchdatei wäre eine Möglichkeit. Kann ich mit xcopy feststellen welche Datei ist neuer?
Luckner.

[Sir Rufo]

Zitat:

Zitat von Luckner (Beitrag 1319952)

Die Kombination von ShellExecute und Batchdatei wäre eine Möglichkeit. Kann ich mit xcopy feststellen welche Datei ist neuer?
Luckner.

Wozu? Prüfe in deinem Programm, ob das, was dort liegt neuer ist als das was du da hast. Wenn dem so ist, dann starte den Update-Vorgang und beende dich selber.

[Captnemo]

ich habe das früher in einem Projekt so gemacht, dass ich neben die neue Exe-Datei noch eine Textdatei gelegt habe, die die neue Versionsnummer beinhaltet.
Ich habe also im Programm beim User zu erst nur die Textdatei geladen und die Versionnr mit der eigenen verglichen, und wenn höher dann halt neue Exe herunterladen starten, eigene beenden, und anschließend umbennen. Wenn nicht höher, dann halt Programm normal laufen lassen.
Wobei ich das über FTP gemacht hatta und nicht über eine Serverfreigabe.

[baumina]

Man könnte die exe auch einfach vom Server starten, statt sie auf jeden PC zu legen.

[Captnemo]

Zitat:

Zitat von baumina (Beitrag 1319962)

Man könnte die exe auch einfach vom Server starten, statt sie auf jeden PC zu legen.

Das könnte man machen. Aber dann hat man das Problem, dass wenn sie ersetzt werden soll, kein Zugriff mehr darauf vorhanden sein darf. Und je nach Nutzungsverhalten kannst du dann als Admin ewig warten, bis die mal frei ist.

[HolgerX]

Ich glaube, das mit der Batch hast ein bischen falsch verstanden..

Nicht die Batch prüft auf neuer, sondern diese führt nur das eigentliche herunterkopieren durch.

das Prüfen erfolgt z.B. mit

Delphi-Quellcode:

if FileAge(ParamStr(0)) < FileAge(UpdateFilepathName) then begin
  ExecuteUpdate(UpdateFilepathName);
  Halt;
end;

Im 'ExecuteUpdate(' wird dann die Batsch-Datei im Temp-Folder erstellt und wie oben geschrieben mit ShellExecute gestartet.

Dann muss deine aktuell laufende Exe nur beendet (Halt) werden.

Die Batch-Datei lädt dann die neue Exe herunter ersetzt die alte und startet diese dann wieder.

Edit: Blubber.. Brauch nen neues Keyboard....

[baumina]

Zitat:

Zitat von Captnemo (Beitrag 1319965)

Zitat:

Zitat von baumina (Beitrag 1319962)

Man könnte die exe auch einfach vom Server starten, statt sie auf jeden PC zu legen.

Das könnte man machen. Aber dann hat man das Problem, dass wenn sie ersetzt werden soll, kein Zugriff mehr darauf vorhanden sein darf. Und je nach Nutzungsverhalten kannst du dann als Admin ewig warten, bis die mal frei ist.

Ist doch kein Problem: exe umbenennen und neue exe draufspielen.

[nahpets]

Zitat:

Zitat von baumina

Ist doch kein Problem: exe umbenennen und neue exe draufspielen.

Solange eine Exe in Benutzung ist, kann man sie nicht umbenennen. Liegt sie also auf dem Server und irgendein Anwender beendet das Programm nicht, hat der Admin ein Problem, da weder umbennen noch ersetzen funktionieren wird.

[baumina]

Zitat:

Zitat von nahpets (Beitrag 1319981)

Zitat:

Zitat von baumina

Ist doch kein Problem: exe umbenennen und neue exe draufspielen.

Solange eine Exe in Benutzung ist, kann man sie nicht umbenennen. Liegt sie also auf dem Server und irgendein Anwender beendet das Programm nicht, hat der Admin ein Problem, da weder umbennen noch ersetzen funktionieren wird.

Komisch, ich mach das immer so, die exe lässt sich bei mir problemlos umbenennen, auch wenn sie in Gebrauch ist. :gruebel:

[Klaus01]

.. ist auch meine Erfahrung, umbennen und verschieben geht, löschen hingegegen nicht.

Grüße
Klaus

[Luckner]

Danke. Ich werde es versuchen so anzugehen, wie HolgerX es vorgeschlagen hat. Das mit der Datei umbenennen ist mir nicht ganz geheuer.
Gruß, Luckner

[Jumpy]

Zitat:

Zitat von Klaus01 (Beitrag 1319984)

.. ist auch meine Erfahrung, umbennen und verschieben geht, löschen hingegegen nicht.

Grüße
Klaus

Wenn da ein DFS im Einsatz ist, kann es da aber auch zu seltsamen Effekten kommen.

[Captnemo]

Über einen entfernten Rechner, der über die Freigabe darauf zugreift klappt das auch oft. Manchmal aber nicht, weil doch noch irgendein Zugriff da ist, der eigentlich nicht da sein sollte.
Wenn man das aber direkt an dem Rechner/Server macht, dann geht das häufig nicht. Habe ich leider schon oft erlebt.

[Back2Code]

Hab das Ganze damals auch mal umgesetzt indem die Versionen abgeglichen wurden und die "neuste" Version welche ich immer in eine Txt die auf Dropbox lag aktualisiert hatte.

Habs jetzt unverändert gepostet

Stand 2013

Delphi-Quellcode:

function CheckForUpdates(): string;
var
  HTTP: TIdHTTP;
  HTTPS: TIdSSLIOHandlerSocketOpenSSL;
  Answer: String;
  data: ISuperObject;
  sUURL, exe, bak, oldexe: String;
  lStream: TFileStream;
begin
  HTTP := TIdHTTP.Create();
  HTTPS := TIdSSLIOHandlerSocketOpenSSL.Create();
  HTTP.IOHandler := HTTPS;
  try
    Answer := HTTP.Get('https://dl.dropboxusercontent.com/u/111435195/Update/updates.txt');
    data   := SO(Answer);
    if data.O['stable'].I['version'] > StrToInt(StringReplace(GetVersion, '.', '', [rfReplaceall])) then
    begin
      try
      UpdateForm.ProgressBar1.Position := 0;
      sUURL := data.O['stable'].S['url'];   // Update URL
      UpdateForm.Label1.Caption := 'Please wait a second ...';
      UpdateForm.ProgressBar1.Position := 5;
      
      oldexe := 'Checker' + '.exe';
      UpdateForm.Show;
      Application.ProcessMessages;
      exe := ParamStr(0);
      bak := ChangeFileExt(EXE,'.BAK');
      UpdateForm.ProgressBar1.Position := 25;
      RenameFile(exe,bak);
      UpdateForm.ProgressBar1.Position := 50;
      lStream:=TFileStream.Create(GetCurrentDir + '/' + oldexe, fmCreate or fmShareDenyNone);
      UpdateForm.ProgressBar1.Position :=75;
      HTTP.Get(sUUrl, lStream);
      UpdateForm.ProgressBar1.Position := 85;
      lStream.Free;
      ShellExecute(0, 'open', PWideChar(oldexe), nil, nil, SW_SHOWNORMAL);
      UpdateForm.ProgressBar1.Position := 100;
      Result := 'true';
      FreeAndNil(HTTP);
      ExitProcess(0);
      except

      end;
    end
    else
      Result := 'false';
      FreeAndNil(HTTP);
  except
    FreeAndNil(HTTP);
    Result := 'error';
  end
end;