Programmupdate bei geöffneter EXE

[Delphi.Narium]

Zitat von himitsu:

Wir haben die Möglichkeiten an all "unsere" Client-Programme, die über's Netzwerk auf die Freigabe zugreifen, einen Shutdown-Befehl zu schicken.
"Programm wird in {frei einstellbarer Zeit} geschlossen".

Das, in Kombination mit dem oben beschriebenen Wartungsfenster von 5:00 Uhr bis 5:30 Uhr, sollte doch eigentlich eine gangbare Lösungsmöglichkeit sein und ohne Launcher, Updater.exe, ... funktionieren.

Einen eigenen Job auf dem Server, auf dem die Exe liegt, einrichten, der jeden Morgen um 5:00 Uhr nachschaut, ob es eine neue Version gibt. Wenn ja, schickt er den Programmen einen Shutdown-Befehl, wartet ein bisserl, bis sich die Programme beendet haben und tauscht dann die Exe aus.

Muss das Programm überhaupt 24 Stunden laufen oder wäre es möglich, dass es sich grundsätzlich um 5:00 Uhr beendet und per Taskplaner (o. ä.) um 5:30 Uhr gestartet wird?

Oder:

Das Programm schaut grundsätzlich um 5:00 Uhr nach, ob's 'ne neue Version gibt. Wenn ja beendet es sich. Punkt.

Der Server schaut grundsätzlich um 5:15 Uhr nach, ob es eine neue Version gibt und tauscht die Exe aus, dies dürfte über den Taskplaner und eine Batchdatei relativ einfach realisierbar sein.

Muss ein laufendes Programm auf 'nem Client eigentlich nach dem Austausch der Exe wieder gestartet werden oder ist es ok, wenn es sich "einfach" beendet? Wenn's wieder benötigt wird, muss der User es am Client halt starten?

[himitsu]

Das Problem mit dem Austauschen ... im Prinzip, mag bei einer EXE gehen.

Bei uns gab es das auch mal (die Funktion für den Shutdown gab es zwar, aber machmal funktionierten die Notifications nicht *1 oder die EXE blieb beim Runterfahren hängen *2)
1) für den Fall wird nun im Programm successive geprüft, ob sich die Datei geändert hat und dann auch der Neustart angestoßen.
2) hier wird nun ein Thread gestartet, der nach x Sekunden ein TerminateProcess ausführt, wenn das Beenden hängt
Manuell hatte Cheffchen die Dateien in dem Verzeichnis gelöscht (INIs und Co. hoffentlich überprungen), was sich nicht löschen ließ umbenannt (*.exe > *.exe.del > weil manchmal Programme lange offen waren oder schnelle Updatefolge auch schonmal *.exe.del_DATUM)
später hatte ich das Vorgehen (bin da bisl faul) durch eine Batch ersetzt, die das automatisch macht. > Zips entpacken in Unterverzeichnis, Backup erstellen (hab ich mal eingeührt) > Dateien löschen und den Rest umbenennen > das Entpackte rüberkopieren (vorher entpackt, um die Dateiintigrität gleich mit zu prüfen, und damit der eigentlich Austausch möglichst schnell geht)

Bei einer EXE geht das noch,
aber bei dynamisch gekladenen Packages und DLLs+Packages raucht es schnell ab, wenn die dann in einem "alten" Programm geladen werden soll und nichts mehr zusammen passt.

Wenn es bei einer Neztfreigabe aber die aktive EXE nach dem Trennen die Verbindung zum "alten" Dateinamen neu aufbaut, anstatt mit einen Verbindungsfehler abzurauchen, dann läd sie eventuell falschen Code in ihren Speicher, wenn Windows vorher das Programm aus dem Speicher ausgelagert und Speicherseiten entladen hatte und der Programmierer kein IMAGE_FILE_NET_RUN_FROM_SWAP benutzt.

[Redeemer]

Wir machen das derzeit auch mit Launcher-EXE. Das sucht in seinem Ordner nach Programmen, die heißen wie es selbst nur mit Suffix.
Außerdem gibt es ein Programm, das ich auf dem Server starte und das automatisch eine mit Datum (und ggf. Buchstaben) benannte Kopie vom aktuellen Kompilat anlegt.

Das hat natürlich Nachteile im Sinne von Performance und wenn Leute das Anpinnen an die Startleiste nutzen würden, würde das auch nicht (lange) funktionieren.

[ZYLAGON]

Habe gestern auch auf Launcher-Programm umgestellt.
Danke für den Input.

VG ZYL

[himitsu]

Ich hatte vor 'ner Weile eine Launcher-Batch gebastelt.

Es gab Probleme mit einem Netzwerk.
Die EXE wird eigentlich direkt auf der Freigabe gestartet, aber dort wurde das nun in ein lokales Verzeichnis kopiert und von dort gestartet,
aber die aktuellen Dateien sollen automatisch von der Freigabe kommen

\\NAS\MyPfad\MyProgramm.exe -parameter

C:\MyPfad\MyProgramm.local.cmd \\NAS\MyPfad -parameter

Eventuel aktive Instanz wird beendet.
Das Verzeichnis wird synchronisiert. (XCOPY)
> XCOPY hat im TestSystem aber einen Nachteil, denn Dateien können nur neuer werden > , aber nicht mehr älter <> , wenn man eine ältere Version zurücksetze, will.
Und die EXE gestartet > Parameter werden durchgereicht, abgesehn vom 1. Parameter.

Als manuellen Link auf dem Desktop
und nochmal in der Aufgabenplanung, wo täglich neu gestartet wird.

Ist eine böse BATCH, mit integrierter EXCLUDE-Datei für's XCOPY. (nur eine Datei, statt Zwei)

Code:

@PROMPT @@$G$S
CD /D "%~dp0"

REM 
REM example: "E:\xxxxx\xxxxx.local.cmd" \\MY-NAS\xxxxx\ -irgendwelche -Parameter
@REM example as single-line command without batch: CMD /C "CD /D "E:\xxxxx"&&TASKKILL /F /IM xxxxx.exe&&ECHO Temp\>xcopy_exclude.txt&&ECHO Backup>>xcopy_exclude.txt&&ECHO xxxxxSrv*.ini>>xcopy_exclude.txt&&XCOPY \\MY-NAS\xxxxx\* .\ /D /S /E /H /R /C /G /K /Z /V /Y /EXCLUDE:xcopy_exclude.txt&&DEL xcopy_exclude.txt&&START "" /B xxxxx.exe -irgendwelche -Parameter

@SET ERR=0

@ECHO.
@ECHO #Source: %~1
@ECHO #Local:  %~dp0
@IF NOT EXIST "%~1\xxxxx.exe" ( ECHO source-directory does not exist && SET ERR=1 )
@IF NOT EXIST "%~dp0\xxxxx.exe" ( ECHO local-directory is not correct && SET ERR=2 )
@IF NOT %ERR% == 0 GOTO error

TASKKILL /F /IM xxxxx.exe 2>NUL

@TITLE Download FileUpdates from %~1
XCOPY "%~1\*" "%~dp0" /D /S /E /H /R /C /G /K /Z /V /Y /EXCLUDE:%~f0
@IF ERRORLEVEL 2 SET ERR=3

@TITLE Start xxxxx.exe
SHIFT /1
START "" /B xxxxx.exe %*
@IF ERRORLEVEL 9059 SET ERR=4

@IF NOT %ERR% == 0 GOTO error
@TIMEOUT /t 5
EXIT /B

:error
@TIMEOUT /t 300
EXIT %ERR%

*** COPY-ExcludeList ***
xxxxx.xxx
xxxxx.ini
Backup
Temp\
.7z
.zip

Mit MyProgramm.exe und MyProgramm.cmd könnte man die hartcodierten Namen durch %~f0.exe ersetzen. (Namen wurden durch xxxx ersetzt)

Man könnte die Copy-Source aber z.B. auch in der CMD oder z.B. einer INI oder der Registry speichern, dann bräuchte man den Parameter nicht.

[haentschman]

Moin...
Danke an Alle.

Zitat:

Soll
1. Die EXE soll ausgetauscht werden ohne die gestarten Instanzen abzuwürgen.

Zitat:

TASKKILL /F /IM xxxxx.exe 2>NUL

...paß nicht.

Ich habe eine Lösung für mich:
1. Build
2. Nach Build:
Consolenprogramm ->
1: Rename der EXE
2: Kopie in einen Ordner (benannt mit den Dateieigenschaften "V_19_20200814_1500") Damit kiegt jede gestartete Instanz seinen eigenen Ordner
3: Kopie des neuen Programms in den Original Ordner

Start über Lauchcher:
1: Prüfung welche Instanzen nicht mehr aktiv sind -> Entfernung des Ordners
2: Start der EXE

In EXE:
1: Prüfung auf neueste Version (Thread) -> optischer Hinweis ("es gibt was Neues")

Vorteile:
1: Da die EXE gleich heißt ist das angepinnte Symbol in der TNA immer noch angepinnt
2: Ich kann 5x hintereinander ein Update einspielen...jeder Neustart kriegt die neueste Version
3: Alle anderen Instanzen laufen normal weiter...mit Hinweis

Nachteile:
1: Bei DB Änderungen müssen alle raus. Das ist aber verträglich.

[himitsu]

Zitat:

...paß nicht.

Ist dort aber auch Absicht.

Mit dynamisch geladenen DLLs und BPLs geht es einfach nicht anders.


Auch wenn es nur eine EXE/DLL ist, oder wo bei Verwendung von BPLs immer alles beim Programmstart geladen wird (niemals dynamisch nachladen),
selbt dann sollte man besser niemals ohne IMAGE_FILE_NET_RUN_FROM_SWAP und IMAGE_FILE_REMOVABLE_RUN_FROM_SWAP ein derartiges Update machen.

http://docwiki.embarcadero.com/RADSt...flags_(Delphi)