,net Framework entladen nach Beendigung COM

[win568]

Hi

Wir verwenden in Delphi eine TLB, die per COM .NET Funktionen in Delphi einbindet. Da wir diese Funktionen nicht immer brauchen, wollen wir nach Beendigung (Freigabe aller COM Funktionen) das geladene .Net Framework auch beenden, da dieses unnötig viel Speicher benötigt. Wie kann man das machen ?? Wir haben hier nichts gefunden.

[sakura]

Du hast leider keine Möglichkeit. Der entscheidende Satz steht auf der MS Seite:

Zitat:

Important

This method does not release resources to the host, unload application domains, or destroy threads. You must terminate the process to release these resources.

...:cat:...

[Bernhard Geyer]

Wenn du wirklich Probleme mit dem Speicher hast gibts 2 Möglichkeiten:

a, Erstellte deine Exe als 64-Bit Version

b, Lagere die .NET-Anbindung in eine eigene Exe aus.

[win568]

Hi

Danke für die Antworten. Die Vorschläge sind leider nicht so einfach umsetzbar. Wir arbeiten an der 64Bit Version, diese ist aber derzeit noch nicht spruchreif. Und eine eigene Exe ist nicht das was unsere Kunden wünschen. Trotzdem danke.

lg

[HolgerX]

Hmm..

Etwas durch die Brust ins Auge: ;)

Packe die TLBs und verwendeten Funktionen in ein separate DLL.
Dann sollte das .Net doch auch entladen werden, wenn die DLL entladen wird..

[win568]

Hallo Holger

Leider verwenden wir auch GUI Controls. Hier wird es dann interessant :)

[Bernhard Geyer]

Zitat:

Zitat von HolgerX (Beitrag 1375360)

Packe die TLBs und verwendeten Funktionen in ein separate DLL.
Dann sollte das .Net doch auch entladen werden, wenn die DLL entladen wird..

Ich würde darauf Wetten das diese nichts bring da das Laden des .NET-Subsystem nicht an die DLL gebunden ist sondern an den Prozess/Exe.

[win568]

Hi

Eine Überlegung wäre eine eigene Exe, die wir hijacken und als MDI Fenster in der Applikation anzeigen. Wollte den Aufwand aber vermeiden.

Wir haben auch noch ein Verhalten in den TOleServer festgestellt, das die Situation verschärft. Die TLB verwendet für manche Klassen OLEServer Ableitungen. Diese benötigen wir, um Events einzuhängen. Wenn ich nun die Klassen freigebe, wird der Refcount der eingebetteten FEventDispatch Instanz nicht mehr 0 und es bleiben Speicherlecks übrig.

Das ganze passiert, da im Queryinterface einmal das Interface mit IsEqualIID mit der IID des Interfaces eingehängt wird (ist ja auch korrekt), aber dann die Methode nochmal aufgerufen wird, bei der zwar in der GUID der gleiche D1 Wert, aber D2-D3 = 0 sind. Dadurch wird ein zusätzliches Interface eingehängt (RefCount = 2) aber beim Beenden wird nur einmal das Release aufgerufen.

[Bernhard Geyer]

Zitat:

Zitat von win568 (Beitrag 1375366)

Wir haben auch noch ein Verhalten in den TOleServer festgestellt, das die Situation verschärft. Die TLB verwendet für manche Klassen OLEServer Ableitungen. Diese benötigen wir, um Events einzuhängen. Wenn ich nun die Klassen freigebe, wird der Refcount der eingebetteten FEventDispatch Instanz nicht mehr 0 und es bleiben Speicherlecks übrig.

Das ganze passiert, da im Queryinterface einmal das Interface mit IsEqualIID mit der IID des Interfaces eingehängt wird (ist ja auch korrekt), aber dann die Methode nochmal aufgerufen wird, bei der zwar in der GUID der gleiche D1 Wert, aber D2-D3 = 0 sind. Dadurch wird ein zusätzliches Interface eingehängt (RefCount = 2) aber beim Beenden wird nur einmal das Release aufgerufen.

In "älteren" Delphi-Versionen (vor Delphi 10) gabs noch einen Bitterbösen Fehler in der Standardimplementierung der überall beim "DefaultInterface" aufgeschlagen ist und die Referenzzählung kaputt gemacht hat.

[sakura]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1375363)

Zitat:

Zitat von HolgerX (Beitrag 1375360)

Packe die TLBs und verwendeten Funktionen in ein separate DLL.
Dann sollte das .Net doch auch entladen werden, wenn die DLL entladen wird..

Ich würde darauf Wetten das diese nichts bring da das Laden des .NET-Subsystem nicht an die DLL gebunden ist sondern an den Prozess/Exe.

Korrekt.

...:cat:...