Ősrégi .dll használata

.NET

Sziasztok!

Adott egy probléma, melyben egy szerveren futó ősrégi programmal kellene kommunikálnom egy most készülő .NET-es programból. Ehhez biztosítva van egy szintén ősrégi C++-ban írt .dll, viszont a .dll függvényeinek hívásakor egyszerűen semmi sem történik. A .dll szerintem rendben van, mert van egy szintén ősrégi kliens program, ami ha betöltjük a .dll-t akkor nagyon szépen kommunikál a szerveren futó programmal. A .dll-hez van dokumentáció, ami nem túl részletes, és van hozzá egy header-fájl is, amivel egy kicsit többre jutottam.

Példa a header-ben lévő függvény deklarációra:

#ifdef DLL_EXPORTS
#define DLL_API __declspec(dllexport)
#else
#define DLL_API __declspec(dllimport)
#endif

extern "C" DLL_API void __stdcall foo(int, int, char*, char*, int);

A most készülő .NET-es programból a következő módon próbálom meghívni ezt a függvényt:
(Nyelv: C#)

[DllImport("DLL neve", EntryPoint="foo", CallingConvention=StdCall)]
public static extern void Foo(int param1, int param2, string param3, string param4, int param5);

Viszont ahogy az elején is említettem a függvény hívásakor nem történik semmi.

Már minden általam eddig ismert, és frissen megismert dolgot próbáltam, de a hívás akkor is "süket fülekre talál".

Van esetleg valaki aki találkozott már ilyen problémával és sikerült megoldania a dolgot?
Szívesen venném ha megosztaná velem a tapasztalatait.

A válaszokat és a jó tanácsokat előre is köszönöm.

  • 1511 megtekintés

( asch v | 2019. 09. 28., szo – 14:31 )

A C# -> C hívási konvenció leképzés az egyik ami hibás lehet.

Mi az, hogy nem történik semmi? Exceptiön nincs-> a szimbólumot megtalálja és rá is teszi a vezérlést. Aztán visszatér, de nem történik meg aminek meg kell történni? Hibajelzés semmi?

Amit csinálnék:

* sima C programmal megnézni, hogy működik-e a dll használata?
* Ha működik beledebuggolni a C programba, hogy minek kellene a stacken/regiszterekben lenni, ha jó a paraméterátadás
* Beledebuggolni a .NET+dll-be, hogy mi van a stacken, amikor meghívja a dll függvényt (a dll függvény belépési pontjára kell tenni a breakpointot)
* Ebből kiderül, hogy mi a hibás -> megjvítani, örülni

Persze a doksi olvasgatása sem elvetendő debuggolás előtt/helyett :-). A string->char* konverzió tuti, hogy rendben van? Nem valami más típussá konvertálja a .NET ezeket a paramétereket?

Ha semmi nem működik, akkor külön kipróbálnám a paraméterek .NET->C átadását egyesével saját C-nyelvű DLL-lel típusonként. Aztán ha működik, akkor írnék egy C függvényt, amit .NET-ből hívnék és továbbhívnám az eredeti függvényt belőle. De ezt már szigorúan a leggyakoribb példaprogram beállításokkal. Hátha a hívási konvencióval, vagy valami hasonlóvan van probléma.

A futás során nincs semmiféle exception.

A konverzióra eddig azért nem gyanakodtam, mert sok .dll-el (pl: kernel32.dll) próbálkoztam (csak sajáttal nem) és nem volt probléma a paraméter átadással.

De minden esetre kipróbálom a javaslatodat, és írok egy saját .dll-t amin először kipróbálom a paraméter átadást, aztán pedig az "Ős" .dll függvényeinek hívását.

( blr v | 2019. 09. 28., szo – 16:49 )

Az ősrégi azért 32 bites? A .NET kódod explicit x86 fordítod? Ilyenkor az AnyCPU nyűgös szokott lenni.

Én nem foglalkozok ilyenekkel, de valami hasonló problémánk volt pár éve egy projektben, aki szenvedett vele, valami olyasmi megoldást talált, hogy becsomagolja a hívást egy C++/CLI kódba, azt hívja C#-ból, és akkor nem az utóbbiban kell szenvedni a két világ összeeegyeztetésével, mert az előbbinek az a dolga.

( Elbandi v | 2019. 09. 28., szo – 17:24 )

meg csinalnek egy mini debug dll-t, benne ugyanugy a foo fuggvennyel, es abban szepen kidumpolnam a parameterket: 


void __stdcall foo(int param1, int param2, char* param3, char* param4, int param5)
{
 printf("param1: %d\n", param1);
 printf("param3: %p: %s\n", param3, param3);
 ...
}

aztan ezt a dllt hivogatva a netes programbol, latod hogy valojaben milyen parameterek ernek at.

megjegyzes: tippre ott a string->char* konverzional lesz elrontva valami, es lehet jol irtak meg azt a foo-t, hibas parameterre nem csinal semmit. https://stackoverflow.com/questions/39987435/pass-char-to-c-dll-from-c-…

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

( uid_4278 | 2019. 09. 28., szo – 21:36 )

Es ha CallingConvention=Cdecl -el probalod?

( sz332 v | 2019. 09. 28., szo – 21:42 )

Ha minden kötél szakad, rakd körbe egy C kóddal, ami indít egy socket-et, aztán azon keresztül kommunikálj.

Irnék egy C kódot, ami
- használja a DLL-t, és
- nyit egy TCP socket-et (HTTP) / vagy valamilyen IPC megoldást
- megvárja, amíg valaki csatlakozik
- tud üzenetet fogadni
- a kapott üzenetből kiszedi az paramétereket
- meghívja a függvényt
- az eredményt visszaadja a hívó félnek

Már nyilván akkor, hogy ha ez megvalósítható a rendszerben.

https://stackoverflow.com/questions/2064103/interprocess-communication-…

( bocs | 2019. 10. 01., k – 19:02 )

Sikerült megoldani?
Depends.exe mit mond rá?
Ha átküldhető privátban, rá tudok nézni.