C#.Net Klassen in C++ MFC Anwendung einbinden?

Hi Jungs, und mal wieder Danke im Voraus;),

ich hab mal nen eigenen sehr Umfangreichen XML-Connector in C# geschrieben.

Jetzt muss ich allerdings in einer anderen CRM Software das damals von mir implementierte XML-Protokoll wiederverwenden. Diese kann jetzt aber nur native c/c++ MFC-Dlls als Plugin laden. Schon ok das Plugin zu schreiben,
aber ich muss doch irgendwie meine vielen eigenen XML-Wrapper klassen, die jew. von XmlNode oder XmlDoc... und so weiter abgeleitet sind, verwenden können.

???Scheiße!!!! Muss ich das alles mit nem c++ XMLProcessor neu schreiben????
Ich hab doch extra 2.0 genommen um für die Zukunft gewappnet zu sein.:(
Ich wollte das Protokoll doch an allen CRM Servern implementieren....
und jetzt können die anderen schon .Net und der Scheiß vom großen Neukunden NICHT!
...
...
...
Gibts nicht vieleicht doch ne Möglichkeit die .NET KLassen und Managed Types oder assemblys in c/c++ Win32/MFC Anwendungen zu verwenden? Geht Pinvoke nicht irgendwie anders herum;).
Hab bis jetzt nicht viel erfahrung mit c++ nur halt mit native c. Bin über C/PERL zu C# gelkommen;)
(in PERL kann man übrigens auch objektorientiert arbeiten:))

Hmm also scheint ja möglichkeiten zu geben, wie sieht es denn mit der Performance von c# und COM aus ?
ist das ne Möglichkeit oder machen die Ableitungen von XmlNode etc. Probleme?

Einfach deine c/c++ dll mit /clr übersetzen und du kannst deine .Net Typen wie gewohnt verwenden.
=>Mixed (Native and Managed) Assemblies

Hallo Schakal,

Du kannst COM verwenden, das wäre auch zunächst das wohl gängigste Mittel um auf .NET Funktionalitäten zurückzugreifen, ABER: Du kannst nicht im Speicher von .NET Anwendungen herumpfuschen. Das heißt, selbst wenn Du es schaffst, dass Du ein Handle oder Zeiger einer .NET Klasse ins C++ durchreichst verursacht ein Lese- bzw / Schreibzugriff auf diesen Speicherbereich eine Fehler auf Seiten von .NET.

Du kannst also ohne schlechtes Gewissen auf Standard Parameter (Int, String etc.) zurückgreifen, wenn Du auf .NET Klassen zurückgreifen willst, dann müssen diese als COM Klassen definiert sein.

Siehe auch viele Beispiele von VB6 zu .NET. Oder z.B. hier:
MSDN - Exposing Framework classes with COM
MSDN - Example C# COM Class

Aber mi COM muss man schon selbst Erfahrungen sammeln, damit man die Pappenheimer kennt 😉

Viele Grüße
Norman-Timo

Einfach deine c/c++ dll mit /clr übersetzen und du kannst deine .Net Typen wie gewohnt verwenden.
=>
>

Danke, das 😉 ist aber anscheinend doch gar net so einfach wie man in der MSDN liest .... 😉 ...

Nach Doku der Schnittstelle muss ich Die mit /MT compilieren.
"/MT is not compatible with /clr";)

What the F**K... (/MT)

Wenn ich dann die einstellung ändere, bekomm ich ohne ende Fehler:) wie z.B:

"Error LNK2005: "public: __thiscall std::_Lockit::_Lockit(int)" (??0_Lockit@std@@QAE@H@Z) already defined in msvcprt.lib(MSVCP80.dll) libcpmt.lib"

" error LNK2005: ___xi_z already defined in MSVCRT.lib(cinitexe.obj) LIBCMT.lib "

"*** already definded in MCVCRT.lib(MSVCR80.dll)"

Diese Linker Fehler bekommst du, wenn du gegen die falsche Runtime-Lib linkst(/MT vs /MTd vs /MD vs ...)

Danke,

also aus dem Linker raus und das Funzt?

krieg ich dann nicht Probleme mit Unmanaged-Interfaces/Klassen usw? oder werden die Typen in den RuntimeLibs polymorph behandet?

Also wenn das läuft, sollte das auch wesentlich performanter sein als über eineen Zwischenwrapper(native c Export) oder?

Dann funzt evtl ja auch ne Serialisierung...

Gibt leider keine Bibel für den Interop zwischen .NET und Win32 ala Petzold oder?

Oder kennt jemand nen richtig gutes online-Tutorial über Mixed Managed/Unmanaged c++ coding?