Austausch eigener DLL

[Manfred]

Hi,

im Moment fällt mir keine bessere Überschrift ein.

Ich habe in den letzten Tagen einige Dinge erlebt, die mich nachdenklich machen, bzgl. DLL.

Eine DLL wird doch nachgeladen in den Speicher und bleibt dort evtl. noch ein Weilchen vorhanden!?

Wenn die DLL im Speicher geladen ist, kann sie dann von der HD gelöscht werden?
Ich habe immer wieder Anpassungen an einer DLL machen müssen, aber irgendwie kamen die Änderungen nicht zum Zuge. Irgendwann nach einer Zeit X, war es dann doch der Fall. Kann es sein, dass die DLL noch im RAM war und deshalb die "neue" DLL nicht zum Zuge kam, oder sehe ich das falsch?

[Martin Altmann]

Hallo Manfred,
ich denke, Du siehst das richtig.
Du kannst sie zwar nicht löschen, aber umbenennen.

Viele Grüße,
Martin

[Manfred]

Hi Martin,

worum es mir geht: Ich denke mal, ich habe dann die Fehlermeldung nicht bemerkt, die kam, weil die Ziel DLL nicht gelöscht werden konnte. Also muß ich mein Batchfile für die Erzeugung ändern.

[Jan]

Hallo Manfred,

ich hatte mit dem Problem in meiner Update-Funktion zu kämpfen. Weil, wie Martin schrieb, eine bestehende und gerade genutzte dll nicht einfach gelöscht werden kann. Ich hab das dann so gelöst, das die betreffende dll umbenannt wird (was ja, wie Martin ebenfalls schrieb, sehr wohl geht), dann die neue reinschreiben, und die alte umbenannte löschen. Das Löschen muß wiederum sein, weil sonst beim nächsten Update nicht mehr umbenannt werden kann, weil ja schon eine Datei mit dem Namen existiert (und außerdem: Wie sieht denn das aus, wenn da Updateleichen im Verzeichnis rumfliegen?).

Jan

[Manfred]

Hi Jan,

ich mache aber das "Update" mit dem Inno Setup. Ich bin nicht so tief da drin, aber geht das dann auch?

Und selbst wenn ich die umbenenne, die alte ist doch noch im Speicher und wird doch dann trotzdem weiter benutzt, oder sehe ich das falsch? Nicht gewünschte Ergebnisse sind doch dann vorprogrammiert.....

[brandelh]

Hallo Manfred,

die alte DLL bleibt im Speicher solange sie benutzt wird. Spätestens beim Abschalten am Abend wird diese beendet und beim nächsten Start wird dann die neue benutzt.

Daher muss aber auch das Installationsprogramm damit umgehen können, dass die alte nicht sofort gelöscht werden konnte !

[Manfred]

Hi Hubert,

gut, dass die max. bis "Rechner aus" drin bleibt, war klar. Es ist halt die Zeit, bis dahin. Und da sehe ich meine Sorge, beim einfachen Umbenennen. Windows merkt ja als solches nicht, dass es eine neue gibt, die dann evtl. neu nachgeladen werden müßte. (jetzt einmal überspitzt gesagt.)

Also, eine andere Philosophie verfolgen......

[brandelh]

Hallo Manfred,

bei jedem Programmstart wird die mit dem richtigen Namen geladen !
Wenn also die EXE beendet wird, kann man die alte DLL umbenennen (sicherer !) und die neue hineinkopieren.
Beim Start der EXE wird dann die neue (zusätzlich) geladen und benutzt !

Kannst du übrigens Ausprobieren, wenn du eine Funktion in die DLL packst, welche eine Versionsinformation zurückgibt.

Ich hatte vor Jahren mit reinen EXE Programmen ein ähnliches Problem beim Update (diese lagen lokal auf dem PC) damals habe ich im Datenverzeichnis auf dem NETZWERK-Laufwerk eine memowrit(cVersion...) Datei erstellt, die jede EXE beim Start gelesen hat.

War die Version gleich, alles OK.
War die Version im Programm neuer, dann wurde der neuere Wert in die Datei geschrieben.
War die Version im Programm älter, dann erfolgte eine Fehlermeldung und per Batchdatei wurde die neue EXE geladen (Programm wurde damals immer über Batchdatei gestartet und je nach Errorlevel wurde danach die EXE ersetzt).

[Jan]

Hallo Hubert,

bei mir hab ich das so geregelt, daß nach einem erfolgten Update (nur weil man die Funktion aufruft heißt das ja noch lange nicht, das da auch was aktualisiert wurde) die Meldung kommt, daß das Programm neu gestartet werden muß. Ich überlasse das dann dem User, ob er das macht oder nicht.

Ich hab aber auch noch nicht überprüft ob es eventuell knallt, wenn er einfach so weiterarbeitet und die dll auf der Festplatte jetzt eine ganz andere ist. Das scheint mir jetzt inzwischen angebracht zu sein

Jan

[Manfred]

Halt,

ich merke, hier liegt wieder ein Denkfehler vor. (bei wem, wird sich klären)

Eine DLL ist ja dazu da um nur 1x in den Speicher geladen zu werden. (stimmt?) Ich habe ja mehrere Programme, die auf ein und dieselbe DLL zugreifen. Das meinte ich damit. Wenn 1 Programm noch in Benutzung ist, dann würde dieser Fall eintreten.

[brandelh]

Hi,

ich bin jetzt zwar nicht der, der mit vielen DLL arbeitet, aber soweit ich weiß wird vom Programm eine DLL nach NAME auf der Festplatte angefordert. Sobald sie im RAM ist geht es wohl über handles.

Somit würden die bestehenden Instanzen (EXE) auf die umbenannte zugreifen, da die handles ja gleich bleiben. Die neu gestarteten EXE Dateien würden die neue DLL von Platte laden.

Ein Problem besteht dann, wenn z.B. Dateizugriffe auf DBF geändert wurden und nun mit verschiedenen Versionen darauf zugegriffen wird (z.B. neue Plausis oder Feldlängen etc.).

ABER eigentlich sollte man ja zumindest die Programme schließen lassen, die auf eine neue Version gehoben werden sollen. Somit würde im Speicher lediglich eine alte DLL Version ohne Zugriffe dümpeln, bevor diese dann vom BS geschlossen wird.

[Manfred]

Hi Hubert,

ich wollte es vorhin nicht so großspurig sagen, aber Du sprichst mir aus der Seele. Bei einem Update haben die Programme geschlossen zu sein, die getauscht werden sollen. Aber in dem Moment, in dem der DAU vor dem PC steht, scheint er einfach kein funktionsfähiges Gehirn mehr im Kopf zu haben. Es passieren Dinge......

Ich denke einmal es wurde einfach zu viel Denkarbeit dem User abgenommen, sodaß er einfach nicht mehr anzukurbeln ist selbst wieder zu denken.

Wir haben es doch nur gut gemeint.

[Martin Altmann]

Und immer schön dran denken:
Bei DllLoad() und DllPrepareCall() werden die Merker jeweils um eins erhöht!
Bei DllCall() auch um eins!
Wer also seine DLLs nur mit DllCall-Aurufen benutzt, ist fein raus - das Betriebssystem weiß also, wann es die DLL als ungenutzt aus dem Speicher entfernen kann.

Viele Grüße,
Martin

[Manfred]

Öööhm,

[Gerd König]

Hallo Manfred,

wir haben das Problem dahingehend gelöst, daß die aktuellen DLLs (und EXEs) auf dem Server liegen und die Applikationen generell über einen Loader gestartet werden. Dieser versucht, alle DLLs, die sich zwischenzeitlich geändert haben, upzudaten. Ist das nicht möglich weil eine andere Applikation diese DLL geladen hat, wird der Startvorgang mit einer entsprechenden Meldung abgebrochen. Damit wird gewährleistet, daß auf einem PC immer nur eine DLL-Version verwendet wird.

Bei tiefgreifenden Updates kann ich von meiner Station aus das Beenden aller relevanten Programme erzwingen. Erst nach Freigabe können dann die Programme wieder gestartet werden.

Bei der ganzen Sache haben wir natürlich den Vorteil, daß wir (150 Arbeitsstationen) der einzige Anwender unserer Programme sind.

Dieses Prinzip ist natürlich auch in diversen Kundennetzen denkbar.

Gruß Gerd

[Manfred]

Hi Gerd,

2 Fragen:

1) Loader?
2) Beenden erzwingen?

Wie muß ich mir den Ablauf und die Funktionsweise vorstellen?

[Jan]

Manfred,

zu 2: Andreas hat ja mal erzählt, das er immer einen Thread laufen lässt, der nachschaut, ob es eine Meldungsdatei auf dem Server gibt. Und wenn da drin steht, daß das Programm beendet werden in einem festgelegten Zeitrahmen soll, das aber nicht passiert ist, dann beendet der Thread das Programm. Einfach so.

Sowas würde ich in meinen Projekten nicht einbauen wollen. Was passiert, wenn der Sachbearbeiter gerade mitten drin ist in einem Datensatz? Oder das gerade eine kritische Situation ist? Andererseits kann ich Andreas aber auch verstehen. Bei uns ist das auch manchmal so, daß alle Anwender wegen eines Datenbank-Updates oder sonstwas das Programm beenden müssen. Und manche machen das einfach nicht. Weil sie nicht am Platz sind, oder einfach keine Lust haben zu tun, was der Admin sagt. Da ist man nur am hinterherrennen.

Jan

[Gerd König]

Hallo Manfred,

zu 2)

Prinzipiell mache ich es so wie Jan beschrieben hat.
Auf der jeweiligen Arbeitsstation erscheint ein extra Fenster mit einer Countdown-Anzeige zum jeweiligen Programm. Diese Fenster kann nicht minimiert, verschoben, in den Hintergrund bebracht oder geschlossen werden. Der Countdown beginnt mit einem Wert von beispielsweise 5 Minuten. Bis zu 2 Minuten vor dem gewaltsamen Ende kann der User noch mit dem Programm arbeiten (außer Auswertungen starten). In den letzten 2 Minuten hat er auf das Programm keinen Zugriff mehr (außer schließen)

zu 1)

Der Loader ist eine Xbase-Applikation, die sich auf dem Server befindet, wo auch die DLLs liegen. Im selben Ordner gibt es eine Datei, in der alle Dateien aufgelistet sind, die auf die lokale Festplatte der Arbeitsstation zu kopieren sind.

Der Loader wird beim Aufruf als Parameter das zu startende Progamm übergeben.
Nach dem erfolgreichen Kopieren (wenn überhaupt erforderlich), wird die eigentliche Applikation mit RunShell() gestartet und die Loader-Applikation geschlossen.

Dadurch können die DLLs auf dem Server jederzeit (außer wenn gerade ein Kopiervorgang läuft ) überschrieben werden.

Anmerkung: Unser Loader macht noch mehr, aber das oben Genannte ist die grundsätzliche Idee.

Das Konzept läuft übrigens seit einigen Jahren problemlos

Gerd

[brandelh]

Hi,

ich habe zu Clipperzeiten eine Batchdatei benutzt, die die normale EXE direkt (lokal) gestartet hat. Diese EXE Datei hat intern eine Variable mit der VERSIONsnummer. Auf dem Serververzeichnis liegt eine Datei mit der neuesten VERSIONsnummer. Wenn die der EXE neuer ist, überschreibt sie die Versionsdatei und meldet somit die neueste Version. Wenn die EXE älter ist, erfolgt eine Meldung ('Neuere Version muss geladen werden') und setzt mit Errorlevel() z.B. 20 und beendet das Programm. Die Bachdatei prüft direkt hinter der EXE den ERRORLEVEL und falls der Wert für Update gesetzt ist, kopierte diese dann die Dateien (gezipt mit entzipper) herunter und installierte (entpacken) diese.
Danach wurde meist die Batch selbst neu gestartet und damit die neueste Version. Unter Xbase++ habe ich für die EXE und die System DLL eine eigene Versionsnummer, damit nur das nötigste geladen wurde.

Mit der Umstellung auf Citrix-Server entfiel der automatische Update, nicht jedoch die Prüfung auf gleiche Versionsstände ...

[Jan]

Hubert,

Unter Xbase++ habe ich für die EXE und die System DLL eine eigene Versionsnummer, damit nur das nötigste geladen wurde.

Genau damit arbeite ich auch. Ich hab die aber, da meine Vorgehensweise eine total andere ist, in die arc-Datei gepackt. Damit folge ich grundsätzlich auch dem Windows-Prinzip, die Version ist damit auch z. B. im Explorer zusehen. Diese Versionsnummer frage ich dann in Xbase++ ab und vergleiche die mit einer Datei, in der die aktuellsten Versionsnummern der exe und der dll stehen. Und nur die wirklich benötigten werden runtergeladen.

Jan

[Manfred]

Hi,

mit den Versionsnummer. Eine Frage:

Wie regelt ihr das in der Entwicklungsphase? Da sollte sich doch eigentlich alle Nase lang die Versionsnummer ändern? Ich muß ja irgendwie unterscheiden, welche Version der/die Tester jetzt gerade haben, um überhaupt zu wissen, wer womit arbeitet.

[brandelh]

Hi Jan,

in der Versionsresource habe ich die EXE Versionsnummer auch stehen.
Über #DEFINE und #INCLUDE sind beide immer identisch.
Intern verwende ich halt wie früher eine Public - die Abfrage der Versionsnummer per API Funktion aus der Resource habe ich noch nicht gelernt

Die der DLL() erzeuge ich mit Version()+"."+alltrim(str(Version(3))) zur Laufzeit.

[Manfred]

Öööööhm,

war die Erklärung jetzt für mich?

[Jan]

Hubert,

bei mir sieht das so aus. Da kommt zwar noch was nach, weil ich die drei Versionsstufen einzeln abprüfe, aber das Auslesen ist ja erstmal das wichtige.

Code: Alles auswählen

// Die gespeicherten Dateiformationen der lokalen Datei auslesen
aVersion := LoadResource(1, cFile, RES_VERSION)

// Es wird nur die Version benötigt
AEval(aVersion, {|e| cVersion := IIf(e[RES_VERSION_KEY] = "FileVersion", e[RES_VERSION_VALUE], cVersion)})

Jan

[andreas]

Hallo Manfred,

das Problem mit den noch im Speicher geladenen DLLs passt nicht nur zu DLLs sondern auch zu EXE-Dateien. Diese kannst nämlich auch umbenennen und neue einspielen, wenn die alte noch in Benutzung ist. Funktioniert meistens auch. Ab und zu gibt es aber doch Probleme. Ich habe zumindest schon ein paar mal auf einem Win2003 Terminal-Server gehabt, dass nach dem Einspielen der Datei die Änderung nicht da war. Nur nach irgendeiner Wartezeit waren die Änderungen da ohne dass in der Zeit was getan wurde.