managed code aufrufen aus einer klassischen C-Style-Funktionen-DLL
-
Hallo Forum!
Ich verwende Matlab, um eine klassische (native) C-DLL mit einigen Funktionen aufzurufen. Nun möchte ich gerne in dieser C-DLL eine managed Klasse (C++ CLI) benutzen.
Dazu lege ich eine native Klasse nach dem Singleton-Pattern an, die wiederrum folgendes Member hat:
gcroot < classname ^> g_tv ;
Sobald ich nun g_tv = gcnew … aufrufe,
erhalte ich eine InteropServices SEHException "Eine externe Komponente hat einen Fehler aufgerufen".
Was heißt denn das, und was kann man da tun?
Wie geht Ihr generell vor, um von unmanaged C-Funktionen (keine C++-Klassen!!) managed Code aufzurufen?Danke!
prrd
-
Wahrscheinlich funktioniert
gcroot<ManagedClass ^> mclass;nur innerhalb einer C++ Klasse.
Was spricht dagegen eine C++ Klasse zu erstellen und diese dann mit mehreren C-Funktionen nachzubauen?
-
Hi,
erstmal vielen Dank für die Antwort.
Ich habe es jetzt so aufgebaut:
class mediatorClass
{int do_something()
{
tv = gcnew managedClass();
}
private:
gcroot< managedClass > tv;
};int DLL_function()
{
mediatorClass * d = new mediatorClass();
d->do_something();
}Auf die Zeile "d->do_something()" in der DLL-Funktion setze ich einen Breakpoint . Sobald er diese Zeile verlässt, und noch bevor er in die do_something Funktion der MediatorClass kommt, tritt die Ausnahme auf.
Ganz schön seltsam, oder?
-
Was denn für eine Ausnahme?
Mit tv machst Du nachher nichts mehr, oder ist das hier nur für Testzwecke?
-
Du scheinst ein ganz anderes Problem zu haben.
Bei mir funktioniert dein Code, außerdem habe ich es jetzt mit einer globalen gcroot Variablen probiert und es geht auch.
Was hast du denn für ein Projekt bzw. wie sehen deine Projekteinstellungen aus?
P.S: Bitte Code Tags verwenden
-
Hallo!
@taraneas -> Was hochinteressant ist, ist, dass wenn ich diesen Code in einem C++/CLI-Konsolenprojekt durchlaufen lasse, dann funktioniert dies bei mir auch. Rufe ich die DLL allerdings über eine andere Software auf - in diesem Fall Matlab - geht das ganze nicht mehr. Ich habe aber schon tausend andere DLLs erstellt und von Matlab aus aufgerufen, kein Problem, nur solche "mixed-mode" DLLs sind offenbar problematisch. Aber warum weiß ich nicht.
@simon.gysi -> mit tv mache ich später noch was, bloß habe ich den Code der Übersichtlichkeit halber so weit wie möglich reduziert.
-
Hast Du es in einer Dll ohne Aufruf aus Matlab, sondern aus einer Win32 Konsolenanwendung probiert?
-
Auf die Zeile "d->do_something()" in der DLL-Funktion setze ich einen Breakpoint . Sobald er diese Zeile verlässt, und noch bevor er in die do_something Funktion der MediatorClass kommt, tritt die Ausnahme auf.
Was für eine Ausnahme?
(Schon mal gefragt...)
-
@ simon.gysi -> sorry, hatte beim ersten mal die Frage übersehen. Debugge ich managed, erhalte ich eine SEHException, nativ erhalte ich "Windows cannot continue from this exception" (?)
@taraneas -> bei einem C++/CLI-Konsolenprojekt, das die DLL aufruf, tritt das Problem nicht auf. Bloß warum?
-
Wie sieht es denn mit einer Win32 Konsolenanwendung aus?
Matlab hat anscheinend seine Probleme mit Managed Code und/oder Daten. Mit einer Win32 Konsolenapplikation könntest Du ausprobieren, ob die Dll richtig gewrapped ist.
-
Ich Rate jedem davon ab solche Dinge zu machen. Es sei denn dier Hersteller hat es explizit erlaubt.
Z.B. hat der Hersteller des Windows-Explorers es *explizit* _verboten_ Shell-Extensions in managed Code zu schreiben.
-
Also bei einem Win32-Konsolenprojekt hab ich das Problem auch nicht. Scheint wirklich an Matlab zu liegen. Vom Matlab-Hersteller habe ich noch nirgends solche Doku gefunden, weiß jemand hierzu was?
Auf jeden Fall tausend Dank für alle Hilfe!!