CLR bleibt bei einer mixed mode DLL im Speicher?

thenoname

Hallo, hab gerade ein unverständliches Problem.
Ich habe in einer C++ DLL Datei einen C# Dialog der ein Grid enthält.

Alles gut soweit, jedoch muss ich wegen dem C++ Hauptprogramm mit einer Wrapper DLL den WPF Dialog öffnen. Auch das klappt, jedoch ist nach einem FreeLibrary die CLR dauerhaft im Speicher vorhanden und geladene Bilder, die mit einem Pfad übergeben wurden, werden nicht losgelassen. Nach dem das Hauptprogramm geschlossen wurde klappt alles wieder.

Ich hab viel gegoogelt aber die Aussage war das ich anscheinend nicht die erzeugten Objekte per Garbage Collector löschen kann und auch einzeln klappt es nicht. (mit gcnew im C++ Code erzeugt)

Grüße,
TheNoName

hustbaer

Wenn die Files gelockt bleiben, dann ist irgendwo Pfusch-Code der Streams nicht sauber zumacht.
z.B. Code der gcnew verwendet anstatt den Stream einfach ohne ^ hinzuschreiben - siehe Antwort hier http://stackoverflow.com/questions/6375618/do-i-need-to-call-delete-on-idisposable-object-in-c-cli-vs-2010-net-4-0

Bzw. falls die Lebenszeit des Streams nicht an einen Scope gebunden werden kann ist gcnew natürlich "OK" - weil nötig. In dem Fall muss man delete verwenden um das Objekt zu disposen.

Ansonsten könntest du noch die CLR selbst hosten. Dann kannst du die CLR einfach niederfahren wenn du sie nicht mehr brauchst. Dabei werden dann auch alle critical finalizers ausgeführt soweit ich weiss. D.h. danach sollten die Files wieder "frei" sein.

thenoname

Hi,

ich verwende dieses Beispiel:
http://www.microsoft.com/germany/msdn/my/softwarehersteller/wpf-how-to.mspx
mit dem Unterschied das das MFC Beispiel eine DLL ist, die ich in ein älteres Programm ohne clr lade.

Allerdings ist das jetzt zuviel Stoff um es durchzulesen
Das mit dem Ersetzten von ^ Pointer im C++ code lässt der Compiler nicht durchgehen.
Delete habe ich versucht, allerdings müsste man das dann wohl bei allen Pointern mit gcnew machen? Das habe ich noch nicht versucht, müsste ich ja alle irgendwohin doppelt verweisen um später zu löschen.

Ansonsten könntest du noch die CLR selbst hosten.

Keine Ahnung wie man das machen kann ausser alles in ein eigenes exe Programm zu packen.

Mechanics

thenoname schrieb:

Ansonsten könntest du noch die CLR selbst hosten.

Keine Ahnung wie man das machen kann ausser alles in ein eigenes exe Programm zu packen.

Ach? Aber dann wüsstest du, wie das geht?

hustbaer

thenoname schrieb:

Das mit dem Ersetzten von ^ Pointer im C++ code lässt der Compiler nicht durchgehen.

Den Satz verstehe ich nicht.

Delete habe ich versucht, allerdings müsste man das dann wohl bei allen Pointern mit gcnew machen?

Nein. Man müsste sich einfach ein wenig mit .NET auskennen.
Alles was IDisposable implementiert muss disposed werden (was C++/CLI als "delete" abbildet).
Und alles was IDisposable nicht implementiert muss auch nicht disposed werden.

Ansonsten könntest du noch die CLR selbst hosten.

Keine Ahnung wie man das machen kann ausser alles in ein eigenes exe Programm zu packen.

Ich hab's auch noch nie gemacht. Aber ich würde mal hier zu lesen anfangen:
http://msdn.microsoft.com/en-us/library/9x0wh2z3(v=vs.90).aspx
Oder mein Google Kung Fu einsetzen.

thenoname

Das mit dem Ersetzten von ^ Pointer im C++ code lässt der Compiler nicht durchgehen.

Meine Erste Idee war es nicht dem gcnew zu vertrauen und folgend Code:

ref class Globals
{ 
	public:
		// declare HwndSource to host a WPF Page
		static HwndSource^ gHwndSource;
		// declare specific WPF Page
		static BizCardFlowPage^ gwcBizCardFlow;
};

in

ref class Globals
{ 
	public:
		// declare HwndSource to host a WPF Page
		static HwndSource gHwndSource;
		// declare specific WPF Page
		static BizCardFlowPage gwcBizCardFlow;
};

umzuschreiben. Der Compiler meint jedoch:

Fehler 4 error C3162: "System::Windows::Interop::HwndSource": Ein Referenztyp mit einem Destruktor kann nicht als Typ des statischen Datenmembers "Globals::gHwndSource" verwendet werden.

hustbaer

Oh boy... globale Variablen.