[.NET] CLR gebruiken vanuit Win32? (Inverse P/Invoke)

[MrBucket]

In het kort: wie kan mij vertellen hoe ik een .NET assembly kan aanspreken vanuit Win32 (zonder COM)?

Ik heb nl. een Win32-applicatie waarvoor ik een plugin wil schrijven in .NET. De manier waarop de betreffende applicatie plugins ondersteunt is door een Win32 DLL te schrijven die een aantal voorgedefinieerde functies implementeert. Echter, omdat de betreffende functies zich niet houden aan de COM-standaard, betekent dit dat ik geen gebruik kan maken van de interop-functionaliteit die .NET biedt.

Ik weet dat het met behulp van P/Invoke mogelijk is om vanuit .NET een Win32 DLL aan te spreken. Nu schijnt het omgekeerde pad (.NET aanroepen vanuit Win32) heel toepasselijk Inverse P/Invoke te heten. En er is bijna niks over te vinden...
Zo rept het MSDN artikel Interoperating with Unmanaged Code bijvoorbeeld met geen woord over Inverse P/Invoke of iets wat erop lijkt. Volgens het artikel Mixed DLL Loading Problem is het zelfs mogelijk om Win32 en MSIL code te combineren in een DLL, maar wederom: geen referenties naar hoe dat dan zou moeten.

Het enige bruikbare wat ik heb gevonden gaat nota bene over Delphi.NET: .NET Interoperability: .NET <-> Win32. In dit artikel heeft de schrijver het over Creative Round Tripping, een proces waarbij men de .NET assembly moet disassemblen, het assembly manifest moet aanpassen om de Win32 exports te definieren en vervolgens het hele verhaal weer moet reassemblen. Klinkt me behoorlijk als overkill in de oren.

Echter, ik ben dat creative roundtripping verhaal nu meerdere malen tegengekomen, wat doet vermoeden dat het 1 van de weinige oplossingen is om .NET code vanuit Win32 aan te roepen.

Wie kan hier eens zijn licht op laten schijnen?

[H!GHGuY]

maak een DLL die jouw COM/.NET-object aanspreekt...

[ Voor 5% gewijzigd door H!GHGuY op 21-08-2006 21:29 ]

[MrBucket]

HIGHGuY schreef op maandag 21 augustus 2006 @ 21:29:
maak een DLL die jouw COM/.NET-object aanspreekt...

Dat is een mogelijkheid, idd. Maar het nadeel hieraan is dat dan een 'echte' COM-DLL wordt waarvan het CLSID en IID eerst op de COM-manier geregistreerd dienen te worden, iets wat ik liever vermijdt als het niet echt nodig is.

Volgens dat creative roundtripping artikel kan de .NET-compiler blijkbaar wel methods exporteren als ware het Win32-functies. Dan moet er toch een manier zijn om die functionaliteit te gebruiken zonder te terug te hoeven vallen op disassemblen en reassemblen?

[H!GHGuY]

kun je in C++/CLI niet de mix maken?

even geprobeerd:

nieuw C++ Class Library project in VS.NET2003

dan deze code in de CPP file dumpen:

C++:

__declspec(dllexport) void blah(int a)
{
    System::Int32 nr = a;
    System::Windows::Forms::MessageBox::Show("blah");
}

compileren en dan kijken met dependency viewer (zit alleszins bij VS6)

[ Voor 82% gewijzigd door H!GHGuY op 21-08-2006 22:15 ]

[MrBucket]

HIGHGuY schreef op maandag 21 augustus 2006 @ 21:58:
kun je in C++/CLI niet de mix maken?

Je bedoelt managed of unmanaged C++? Geen idee, ik moet zeggen dat ik daar weinig kaas van heb gegeten...

Iemand anders die hier iets zinnigs over kan roepen?

[__fred__]

Waarom zou een mixed assembly in C++ niet werken? Het is mogelijk om middels de /clr compiler switch aan te geven dat je DLL zowel unmanaged als managed code bevat. Deze kan ook gewoon geladen worden (als je ff op wat kleine dingetjes let) vanuit een win32 host proces. (vooropgesteld dat het .NET framework wel geinstalleerd is natuurlijk).

zie ook http://msdn2.microsoft.com/en-us/library/x0w2664k.aspx

spuit elf. C++/CLI dus.

[ Voor 3% gewijzigd door __fred__ op 21-08-2006 22:07 ]

[MrBucket]

__fred__ schreef op maandag 21 augustus 2006 @ 22:06:
Waarom zou een mixed assembly in C++ niet werken? Het is mogelijk om middels de /clr compiler switch aan te geven dat je DLL zowel unmanaged als managed code bevat. Deze kan ook gewoon geladen worden (als je ff op wat kleine dingetjes let) vanuit een win32 host proces. (vooropgesteld dat het .NET framework wel geinstalleerd is natuurlijk).

zie ook http://msdn2.microsoft.com/en-us/library/x0w2664k.aspx

spuit elf. C++/CLI dus.

Nou, geen spuit elf hoor.
Die link die je gaf gaat me volgens mij een heel stuk in de juiste richting helpen...

Maar andere suggesties en opmerkingen blijven natuurlijk welkom

[MTWZZ]

Op codeproject staat wel een sample/proof-of-concept maar ik weet niet of het nuttig is.
Misschien dat je er wat aan hebt: http://www.codeproject.com/csharp/win32_to_net.asp

Ik vrees dat je echter de CLR zelf moet hosten en via die weg functies kan callen. Op GotDotNet staat wel wat interessante info:
CLR Hosting en CLR Hosting via Managed C++ extensions

[H!GHGuY]

ik heb m'n laatste post ge-edit met een klein codevoorbeeldje.

normaal heb je daar wel genoeg aan

[MrBucket]

Allemaal hardstikke bedankt voor jullie reacties, het is me inmiddels gelukt een .NET DLL te schrijven die Win32 functies exporteert.

Een paar dingen waar ik tegenaan liep en die misschien wel handig zijn voor anderen om te weten:

Standaard wordt de C runtime library niet meegelinkt, wat voor linker errors kan zorgen (onder meer over de new operator en CxxCallUnwindDtor). Kies de juiste library (zie hier), en voeg de betreffende .lib-file toe aan de Additional Dependencies (Project properties, op de Linker / Input pagina). Voor mij voldoet msvcrt.lib.

Omdat het een C++-project betreft, wordt ook C++ name mangling toegepast.D.w.z. dat de functies die gedeclareerd zijn met _declspec(dllexport) een andere naam krijgen voor de 'buitenwereld'. Om te zien onder welke namen je functies geexporteerd zijn kun je het freeware tooltje Dll Export viewer gebruiken. Wil je geen name-mangling hebben, dan moet je je functie-declaraties in een 'extern "C"' blok plaatsen:

C++:

extern "C"{
   //Functiedeclaraties
}

[LordLarry]

De Delphi.Net compiler kan dit overigens ook zonder problemen.