Programmupdate bei geöffneter EXE

[haentschman]

Hallöle...8-)

Ich weiß mir keinen Rat mehr...:?

Gegeben:
1. Server 2012, EXE(xxx) liegt auf dem Server, 10 Mal von externen Computern gestartet

Soll
1. Die EXE soll ausgetauscht werden ohne die gestarten Instanzen abzuwürgen. Beim nächsten Start soll die neue EXE genommen werden. Die Kopie heißt: xxx.exe_

Ich habe mir sagen lassen, daß die EXE umbenannt werden kann und die neue EXE in den Ordner kopiert werden kann. Soweit so gut. Habe ich zig Mal auf dem Server mit der Batch ausprobiert. (Testinstanz) :? Gestern wollte ich das mit dem Original machen...Die Kopie "Zugriff verweigert" beim Löschen der Kopie. :evil: Die Kopie ließ sich auch nicht entfernen.

Batch:

Code:

echo off

if exist W:\Blubb\xxx.exe_ del W:\Blubb\xxx.exe_
if exist W:\Blubb\xxx.exe rename "W:\Blubb\xxx.exe" xxx.exe_

copy W:\Blubb_Update\Blubb\xxx.exe W:\Blubb

Geöffnete Dateien:
Die Kopie ist nicht gelistet gewesen. :gruebel:

Ich habe das dann wieder wie immer machen müssen...alle Instanzen raus. (Dann ließ sich die Kopie auch löschen :gruebel:) und manuell kopieren. :?

Wo liegt der Fehler?

PS: beim nächsten Mal probiere ich das ohne das Löschen der Kopie aus.

Danke.

[jobo]

Es gibt auch für EXEn sowas wie einen DLL Cache. Das OS startet dann von alleine eine Copy sodass das Original getauscht werden kann..
Weiß grad nicht wie das genannt wird.

[Sherlock]

Das Umbenennen hat mit alten Windows Server Versionen geklappt, aber heutzutage nicht mehr unbedingt. Ich denke, es lässt sich nicht vermeiden, die geöffneten Dateien zu schließen.

Sherlock

[dataspider]

Ich mache das genau so und hab mich damit abgefunden, dass ich dass nur 1 Mal machen kann, solange noch 1 User die EXE gestartet hat.
Nach dem Umbenennen ist die EXE_ trotzdem noch in Benutzung und kann erst gelöscht werden, wenn der letzte Benutzer "raus" ist.
Ich müsste beim 2. Mal die EXE dann anders benennen (z.B. EXE_2).

Frank Reim

[Der schöne Günther]

Das ist doch Murks. Entweder stellt die Anwendung beim Start fest ob sie auf einem Netzlaufwerk oder lokal liegt. Wenn nicht, kopiert sie sich in irgendein Temp-Verzeichnis und startet sich da.

Oder du machst einen kleines "Launcher"-Programm das nichts anderes tut als die jeweils neuste .exe-Datei zu starten. Du kannst also direkt neue Versionen dort ablegen und hast den Vorteil dass alte Versionen weiterhin bestehen bleiben könnten.

Code:

\\myServer\myFolder
  Mein Programm (hier klicken).exe
  app_1.0.5.exe
  app_1.0.6.exe

usw.

[Bernhard Geyer]

Zitat:

Zitat von haentschman (Beitrag 1471632)

Ich habe mir sagen lassen, daß die EXE umbenannt werden kann und die neue EXE in den Ordner kopiert werden kann. Soweit so gut. Habe ich zig Mal auf dem Server mit der Batch ausprobiert. (Testinstanz) :? Gestern wollte ich das mit dem Original machen...Die Kopie "Zugriff verweigert" beim Löschen der Kopie. :evil: Die Kopie ließ sich auch nicht entfernen.

Das mit dem Löschen können von in Benutzung befindlichen Exe funktioniert seit 20 Jahren nach dem Zufallsprinzip.
Jedes Windows Update könnte dafür sorgen das es jetzt geht oder das es nicht mehr geht.

[haentschman]

Moin...:P

Zitat:

Nach dem Umbenennen ist die EXE_ trotzdem noch in Benutzung und kann erst gelöscht werden, wenn der letzte Benutzer "raus" ist.

:evil: aber auch logisch.

Zitat:

Ich denke, es lässt sich nicht vermeiden, die geöffneten Dateien zu schließen.

Mist...Wieder Arbeit umsonst. :?

Ich habe einen Updater welchen ich noch einbauen kann. Da müßten die Instanzen aber lokal liegen. Und genau das ist derzeit nicht möglich. :? Deswegen hatte ich nach einer Alternative gesucht.

Ich hatte noch einen Versuch die Instanzen von außen zu entfernen (Batch als Admin über Link):

Code:

echo off
taskkill /s SERVER /U USER /p PASSWORT /f /im "xxx.exe"

...irgendetwas wollte da auch nicht. :gruebel:

Zitat:

Ich müsste beim 2. Mal die EXE dann anders benennen (z.B. EXE_2).

Eine Idee hätte ich noch. Ich kann damit leben, daß die Kopien der Instanzen in einem separatem Ordner (exe_temp) liegen. (xxx.exe_1 ... xxx.exe_999 oder so) Ich bräuchte nur eine Batch, die prüft ob der Dateiname xxx.exe_? noch "frei" ist. Jeden Sonntag kann dann das exe_temp, nach dem entfernen aller Instanzen, bereinigt werden.

Könnte ihr mir helfen die Batch zu schreiben? Da bin ich zu lange raus...:oops:

[KodeZwerg]

Wir machen solche Aktionen beim nächtlichen Backup, wo ja eigentlich eh alle offline sein sollten.

[haentschman]

Zitat:

wo ja eigentlich eh alle offline sein sollten.

Software 365/24 in Benutzung...:zwinker: Bei Bedarf (Absprache): Je Tag zwischen 05:00 und 05:30 Update einspielen. :? Das wollte ich nicht mehr. Auch die Handgriffe sind mir zu manuell. (Anmelden(ich mache Update), Remotedesktop, geöffnete Dateien schließen, Explorer, manuelles Kopieren, Abmelden(Update fertsch))

Der Build Process ist automatisiert...bis auf das Tauschen der EXE.

[Der schöne Günther]

Ich verstehe nicht warum du es dir so schwer machst. Keep it simple, stupid.

Zitat:

Zitat von Der schöne Günther (Beitrag 1471638)

Oder du machst einen kleines "Launcher"-Programm das nichts anderes tut als die jeweils neuste .exe-Datei zu starten. Du kannst also direkt neue Versionen dort ablegen und hast den Vorteil dass alte Versionen weiterhin bestehen bleiben könnten.

[haentschman]

Zitat:

Ich verstehe nicht warum du es dir so schwer machst. Keep it simple, stupid.

Weil in der EXE noch ein hardgecodeter Pfad drin ist und der auf einen Unterordner des Programmverzeichnisses zeigt mit ca. 180GB Daten. :evil:

Die Trennung (Daten/EXE) ist schon beschlossene Sache...Aber alles kann ich nicht auf einmal. :?

[KodeZwerg]

Hab grad was gelesen aber kann es nicht prüfen.
Dein "updater.exe" oder "update.bat" kann deine target.exe nicht löschen da es geöffnet ist (prozess target.exe läuft)
Aber anstelle target.exe zu löschen und eine neue target.exe da hin kopieren, soll wohl ein umbenennen funktionieren (target.exe -> target.exe.bak) während target.exe läuft.
Nun die neue updated_target.exe nach target.exe kopieren.
fertig.

sobald der pc neu startet sollte nun die aktualisierte version starten.


Meine Winapi Recherche dazu:
MoveFileExW mit "MOVEFILE_DELAY_UNTIL_REBOOT" Nutzung.
Aber ob das über Netzlaufwerke klappt = kA.

[shebang]

Wäre ein Softlink denn keine Alternative? Da kannst du einfach das Ziel des Links ändern.

[haentschman]

Zitat:

Aber anstelle target.exe zu löschen und eine neue target.exe da hin kopieren, soll wohl ein umbenennen funktionieren (target.exe -> target.exe.bak) während target.exe läuft.
Nun die neue updated_target.exe nach target.exe kopieren.

Zitat:

Ich mache das genau so und hab mich damit abgefunden, dass ich dass nur 1 Mal machen kann, solange noch 1 User die EXE gestartet hat.
Nach dem Umbenennen ist die EXE_ trotzdem noch in Benutzung und kann erst gelöscht werden, wenn der letzte Benutzer "raus" ist.
Ich müsste beim 2. Mal die EXE dann anders benennen (z.B. EXE_2).

...wenn einer die Umbenannte exe als Instanz hat kann man sie nicht nochmal umbenennen. :?

[KodeZwerg]

Hmmm... dann halt, wie windows des auch macht, eine "(1)" "(2)" usw hinten ranhängen und bei neustart all diese backups killen?

Bzw Winapi mal testen :)

[stahli]

Zitat:

Zitat von haentschman (Beitrag 1471650)

Zitat:

Ich verstehe nicht warum du es dir so schwer machst. Keep it simple, stupid.

Weil in der EXE noch ein hardgecodeter Pfad drin ist und der auf einen Unterordner des Programmverzeichnisses zeigt mit ca. 180GB Daten. :evil:

Die Trennung (Daten/EXE) ist schon beschlossene Sache...Aber alles kann ich nicht auf einmal. :?

Hmm, ich bin da beim Schönling und verstehe Dein Problem nicht...

Wenn die Nutzer MyProg.Exe starten kann dieses die höchst verfügbare Datei MyProg000.exe ... MyProg999.exe suchen, diese starten und sich selbst beenden.

Der Launcher kann sogar ältere Versionen versuchen zu löschen (was halt fehl schlägt, sofern noch Instanzen laufen).

So brauchst Du nur eine neue Version in den Pfad legen (nach Eintragung einer neue "Dateinummer") und der Rest geht automatisch.

Wenn natürlich eine neue Datenstruktur oder neue Unterordner vorausgesetzt werden, würde das nicht mehr reichen. Aber das wäre ja bei allen Lösungen so.

[stifflersmom]

Mein Deployvorgang sieht so aus, dass ich die neue Programmversion unter einem (festen) neuen Namen in dem Verzeichnis der ursprünglichen Exe ablege.
Dann startet per Aufgabenplanung morgens um 04.00 Uhr ein kleines Batchskript, dass bei Vorhandensein der neuen Programmversion alle Instanzen der alten Exe mit Taskkill beendet und dann die alte Exe in EXENAME_JJJ_MM_TT.exe umbenennt und die Neue dann in den alten Namen umbenennt.

[himitsu]

Zitat:

Zitat von haentschman (Beitrag 1471632)

Ich habe mir sagen lassen, daß die EXE umbenannt werden kann und die neue EXE in den Ordner kopiert werden kann.

Das kommt drauf an, wie/wo die Datei geöffnet ist.

Eine EXE wird als MMF in den Speicher geladen und das File-Handle geschlossen.
Wenn die Datei dann z.B. auf einem lokalen Laufwerk liegt, dann lässt es sich umbenennen.

Ist dazwischen aber z.B. ein umgeleitetes Verzeichnis (andere Festplatte) oder gar ein Netzlaufwerk dazwischen, dann kommt es dran an, wie dort die Dateien weitergereicht werden.


Also ja, es geht, aber nicht immer.
Schon garnicht geht es, wenn ein DateiHandle (CreateFile, TFileStream, ...) existiert, z.B. um gewisse "Ressourcen" aus der Datei zu holen,
oder der nette Vierenscanner guckt grade rein, usw.

Am Einfachstes/minimalistischsten ist wohl die Batch im Temp-Verzeichnis.
Die Batch kann ich am Ende auch selbst löschen. (wobei es im Temp-Verzeichnis auch so irgendwann bestimmt gelöscht wird)

Zitat:

wenn einer die Umbenannte exe als Instanz hat kann man sie nicht nochmal umbenennen

Lange nicht mehr probiert (zuletzt im Win7)
Aber es ist schon möglich mehrmals umzubenennen und den Platz mit neuen Dateien zu belegen und zwischendrin auch mehrmals den selben Namen wiederverwenden.

[Dalai]

Mit Batch-Skripten oder sonstigen ausführbaren Dateien im TEMP bzw. im gesamten Nutzerprofil wäre ich vorsichtig. Sowas knallt gerade in Unternehmen ganz schnell, wenn SRPs (Software Restriction Policies) oder AppLocker eingesetzt wird.

Grüße
Dalai

[Keldorn]

Hallo

ich mach das auch über eine starter Exe. die startet dann die eigentliche Exe und kopiert noch ein paar Dateien in lokale Verzeichnisse, hier erfolgt ein Abgleich über eine Versionsini. Die starter exe übergibt noch als Parameter das Verzeichnis und so passen auch alle Pfade. Komme gut damit klar und so auch sicherstellen, dass jeder user auf stand ist.

Gruß Frank

[Moombas]

Naja, braucht man eine "extra" starter exe wirklich?
Du kannst doch auch so vorgehen:

1. Dein Programm prüft als allererstes (im Create) ob eine neue Version vorliegt (idealerweise auf einem Netzlaufwerk oder anders erkennbar).
2. Wenn ein Update vorliegt, ein Update Programm starten, diesem die PID mitgeben, und das Programm beenden.
3. Der Updater wartet bis die PID nicht mehr existiert, macht das Update und startet danach dann wieder das Programm.

Achtung: Auf ein Update der Update.exe muss vorher im Hauptprogramm geprüft und aktualisiert werden!

Nachteil: Das Programm muss lokal gestartet/installiert werden und kann nicht aus dem Netzlaufwerk heraus gestartet werden.
Vorteil: Das Programm startet schneller als über eine extra starter-exe (außer natürlich beim Update), da man nicht immer exe1 startet exe2 hat, sondern nur im Updatefall. Es können alle bis zum nächsten Start mit ihrer Version arbeiten.

Zusätzlich mal folgender Denkanstoß:
Lass das Programm doch wie oben in Punkt 1 beschrieben Regelmäßig auf Updates prüfen (z.B. alle Stunde). Wenn es eins gibt -> Hinweis an den Benutzer und Aufforderung zur Ausführung. Vorgehensweise wie oben.

Hätte den Vorteil, das du jederzeit ein Update zur Verfügung stellen könntest ohne dir Gedanken über dessen Einspielen machen zu müssen.

[haentschman]

Danke für die Infos...:P
@Moombas
So wie du es beschreibst, mache ich das bei meinen anderen Anwendungen. :thumb:

Zitat:

Nachteil: Das Programm muss lokal gestartet/installiert werden und kann nicht aus dem Netzlaufwerk heraus gestartet werden.

...die einzige EXE liegt auf dem Server und wird von den Clienten von dort gestartet. Das kann ich momentan nicht ändern. :?

PS:
Ich habe mich für die Variante mit dem Launcher und den seperaten "Temp" Ordnern für die EXE entschieden. Mit unterschiedlichen Dateinamen gab es Probleme mit dem angehefteten Symbol der TNA. :?

[Moombas]

Hmm, nicht ganz ernst gemeint:
Vorm Update-einspielen, das Netzlaufwerk trennen, dann fliegen alle aus dem Programm und danach Updaten. :P

[haentschman]

Zitat:

Vorm Update-einspielen, das Netzlaufwerk trennen, dann fliegen alle aus dem Programm und danach Updaten

...:stupid: hast du dann danach einen neuen Job für mich? :wink:

[KodeZwerg]

Zitat:

Zitat von haentschman (Beitrag 1471768)

...:stupid: hast du dann danach einen neuen Job für mich? :wink:

Strippenzieher wäre dann passend :mrgreen:

[himitsu]

Zitat:

Strippenzieher

Beim Galgenbauer oder lieber beim Geigenbauer?

Man kann aber auch in der Systemverwaltung irgendwo die aktiven Freigabe-Verbindungen zu den Dateien trennen (virtuelles selektives Strippenziehen).

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".

[KodeZwerg]

Zitat:

Zitat von himitsu (Beitrag 1471779)

Beim Galgenbauer oder lieber beim Geigenbauer?

Wenn er so drauf ist wie ich dann beim Geiger "Boss of BigBlocks" :cheers:

[Delphi.Narium]

Zitat:

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

Delphi-Quellcode:

\\NAS\MyPfad\MyProgramm.exe -parameter

Delphi-Quellcode:

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

Delphi-Quellcode:

>

, aber nicht mehr älter

Delphi-Quellcode:

<>

, 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...:P
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. :zwinker:

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 :thumb:

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

[himitsu]

Zitat:

...paß nicht.

Ist dort aber auch Absicht. :stupid:

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)