,net Framework entladen nach Beendigung COM

[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 von HolgerX:

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 von win568:

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 von Bernhard Geyer:

Zitat von HolgerX:

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.

......

[win568]

Hi

Wir verwenden derzeit D10 Seattle. Zu alt ??

[Memnarch]

Das .Net-SUbsystem lässt sich nicht mehr entladen. Was wohl möglich ist, ist das laden von .Net Libraries in eine neu erstellte Appdomain und das anschließende entladen der Appdomain (.Net Subsystem bleibt weiterhin im Prozess, aber nicht die neu geladenen Bibliotheken). Wüsste aber nicht wie man das für COM-Interfaces hinbekommt :/