Windows Cache beim Laden der EXE spinnt...oder?

**haentschman**

Moin...

Zitat:

Ein Loader kopiert die jeweils aktuelle auf den lokalen PC und benennt sie da um

Zum Programm gehört nicht nur die EXE. Die EXE und DLL sollen da bleiben. Ich will nicht an jedem Arbeitsplatz die komplette Installation pflegen müssen.

Zitat:

Und dann kann der Loader diese immer gleich benannte lokale Datei starten

Da bin ich dann bei einer lokalen Installation mit Updater.

Zitat:

Mit den folgenden Einstellungen konnten wir auch schon einige, unregelmäßig auftretende Fehler beheben

...hab ich schon drin. {$SetPEFlags IMAGE_FILE_REMOVABLE_RUN_FROM_SWAP or IMAGE_FILE_NET_RUN_FROM_SWAP}

Zitat:

Jede neue Version bekommt hier auch ihre eigene Versionsnummer

Diese Frage hatte ich schon ein paar Threads vorher im Kopf.

Ich werde mal jede Version über die Buildnummer automatisch "eindeutig" machen und das Ganze beobachten.

**HolgerX**

Hmm..

a) Ihr dreht euch im Kreis..

b) Wenn ein Update einer EXE aufgespielt werden soll, dann geht dies nur 'sauber' wenn diese Exe von keinem client mehr 'geöffnet' ist.
Unter Windows selber wird nach dem 'öffnen' mit Dateinamen diese nur noch per Handle angesprochen. Deshalb funktioniert das umbenennen und ablegen mit gleichem Namen, da das Handle immer noch auf das andere File zeigt. Da helfen auch die PE-Flags nicht, da diese erst beim Öffnen der neuen EXE greifen!

Bei einigen Windows-Versionen, gerade bei den Serverversionen, geht diese Umbenennung, bei anderen nicht, dass hängt auch davon ab, mit was für einem Client auf das Share/die EXE zugegriffen wird.
Auch ist es so, dass per Share noch auf die alte, umbenannte (durch einen Client noch geöffnete) EXE zugegriffen wird, bis auch der letzte Client diese 'freigegeben' hat. Da wird von Windows einfach nur eine Handle-Kopie der geöffneten weiter gereicht.

Wenn Du Sicherstellen willst, dass 'wirklich' alle Clients mit der neuen Version arbeiten, dann müss vor dem Update die Exe auf allen Clients beendet werden. Dies kannst Du auf dem Server prüfen unte Verwaltung/Freigaben/Geöffnete Dateien.

( Dies basiert auf meinen Erfahrungen mit Windows-Servern und EXE von Share starten

)

**haentschman**

Zitat:

dann müss vor dem Update die Exe auf allen Clients beendet werden. Dies kannst Du auf dem Server prüfen unte Verwaltung/Freigaben/Geöffnete Dateien.

...dann wäre ich auf dem Stand von vor 2 Jahren.

Ich konnte damals nur ein Update einspielen nach 21:00. Wenn mal was schief gelaufen ist, tagsüber alle rausschmeißen bei 365/24 Betrieb. Never zurück.

**Sinspin**

Zitat von haentschman:

...dann wäre ich auf dem Stand von vor 2 Jahren.

Ich konnte damals nur ein Update einspielen nach 21:00. Wenn mal was schief gelaufen ist, tagsüber alle rausschmeißen bei 365/24 Betrieb. Never zurück.

Du arbeitest direkt mit Programm das vom Share gestartet wird?
Eine lokale Kopie macht wenigstens nicht bei allen Probleme.

Ginge es, mit einem Loader zu arbeiten und das eigentliche Programm als dll zu liefern? Dann bleibt der Loader(die exe) immer gleich. Die Systray Einstellungen ändern sich dann auch nicht.
Und die Dll könntest Du jedesmal mit einem neuen Namen (Name + Buildnummer??) erzeugen.

**himitsu**

Nja, für langsame PC/Netzwerke hatte ich hier mal eine kleine Batch geschrieben, die hat beim Start die Dateien von einem Netzlaufwerk in einem lokalen Verzeichnis aktulaisiert (XCOPY) und dann die EXE gestartet.
Also statt der EXE wird dann die CMD aufgerufen, als ersten Parameter der Netzwerkpfad und dann die weiteren Parameter an die EXE durchgereicht.
Auf langsamem Rechner mit langsamen/instabilem WLAN dauert es ewig, bis gefühlt 2 Millionen DLL/BPL von DevExpress und Co. geladen sind und das Ladefortschrittsfenster der Anwendung endlich auftaucht.
(inzwischen wurde die Funktion in eine LoaderEXE verschoben)

Pervers finde ich immernoch, dass {$SetPEFlags IMAGE_FILE_REMOVABLE_RUN_FROM_SWAP or IMAGE_FILE_NET_RUN_FROM_SWAP} in der EXE definiert nicht auch für "alle" DLL/BPL gilt.
Vor allem bei Fremdkompilaten ist das echt blödsinnig. (man kann ja nicht alles selbst kompilieren und es ist auch nicht immer möglich überall nachträglich ab deb Bits der PEFlags rumzupfuschen)
Soeine Option gehört auch garnicht in jede DLL, denn die kann garnicht wissen, wie/wo sie mal verwendet wird. (abgesehn davon seh ich keinen Grund soeine Funktion nicht standardmäßig im OS zu aktivieren)