C# DLL in Delphi nutzen

[sonny2007]

Hallo Zusammen

(Delphi 10.4)

Ich möchte gerne eine function aus einer C# DLL in delphi aufrufen und verwenden.
Die C# Dll sieht so aus

Code:

using MessagePack;
using RGiesecke.DllExport;
using System;
using System.Runtime.InteropServices;

namespace MsgPack.Native
{
   public class Exports
   {
      [DllExport(CallingConvention = CallingConvention.StdCall)]
      [return: MarshalAs(UnmanagedType.BStr)]
      public static string ConvertToJson(IntPtr pBytes, int cBytes)
      {
         byte[] data = new byte[cBytes];
         Marshal.Copy(pBytes, data, 0, cBytes);
         string result = MessagePackSerializer.ConvertToJson(data);
         return result;
      }
   }
}

Die definition in Delphi sieht aktuell so aus.

Delphi-Quellcode:

type
  TConvertToJson = function(pBytes: Pbyte; cBytes: Integer): string; stdcall;

Der Aufruf

Delphi-Quellcode:

dllhandle := loadlibrary('MsgPack.Native.dll') ;
  if dllhandle <> 0 then
    @ConverToJson := GetProcAddress(dllhandle, 'ConvertToJson');
    if @ConverToJson <> nil then   // <<--------------- Ist immer NIL
    begin

und so würde der Aufruf selber aussehen.

Delphi-Quellcode:

tmp := ConverToJson(@buf[0], length(Buf));

Jedoch gib GetProcAdress gibt immer NIL aus
Was mache ich falsch?

Grüße
s0n

[Der schöne Günther]

Delphi-Quellcode:

LoadLibrary(..)

aber funktioniert?

[sonny2007]

Ja LoadLibrary geht

[TSchnuckenbock]

Mein nächster Ansatz wäre: Mit dem DependencyWalker in die dll gucken, ob unter "ConvertToJson" auch was drin steht?

[Der schöne Günther]

Oh, verrückt. Ich hätte erwartet dass man das in .NET noch auf "AnyCPU" oder so hatte (statt x86 oder x64) - Aber wenn LoadLibrary(..) an sich funktioniert dann scheint es daran ja wohl nicht zu liegen...

[arnold mueller]

könntest du die DLL mal hier zur Verfügung stellen?

[Aviator]

Ich wollte damals auch mal eine in C# geschriebene DLL in Delphi nutzen. Dafür musste dann die DLL aber mit einem speziellen Unmanaged Exports Helper kompiliert werden. Ansonsten sind die nicht wirklich sichtbar. Ob sich daran etwas geändert hat (vor allem auch mit den Attributen die ja gesetzt sind) weiß ich nicht. Glücklicherweise hatte ich die DLL damals selbst geschrieben und konnte das dann auch selbst alles machen.

Aber dem Tipp mit dem Dependency Walker solltest du definitiv folgen um zu sehen ob überhaupt etwas exportiert wird.

[venice2]

Hmmm...

Code:

function ConvertToJson(pBytes: Pbyte; cBytes: Integer): string; stdcall; external 'MsgPack.Native.dll';

[Aviator]

Bringt nur nix wenn die Methode gar nicht exportiert wird und unterscheidet sich auch nicht wirklich von seiner Version. Oder übersehe ich etwas?

[venice2]

Zitat:

Zitat von Aviator (Beitrag 1504002)

Bringt nur nix wenn die Methode gar nicht exportiert wird und unterscheidet sich auch nicht wirklich von seiner Version. Oder übersehe ich etwas?

Jo warum dann LoadLibrary (gar nicht nötig) wenn sich die DLL im Anwendungspfad befindet.
Entweder es kommt was zurück beim direkten Aufruf oder nicht.

Und sie wird exportiert!

Code:

[DllExport(CallingConvention = CallingConvention.StdCall)]

[Aviator]

Delphi-Quellcode:

LoadLibrary()

hat den Vorteil des Lazy Loadings. Wenn die DLL also nicht beim Programmstart direkt zur Verfügung stehe muss, dann kann man die auch erst verzögert laden. Macht den Anwendungsstart ggf. auch etwas schneller.

Und nur weil das Attribut darüber steht heißt das bei C# nicht zwangsläufig, dass die Methode auch exportiert wird. Zumindest ist das meine Erfahrung.

[venice2]

Zitat:

Und nur weil das Attribut darüber steht heißt das bei C# nicht zwangsläufig, dass die Methode auch exportiert wird. Zumindest ist das meine Erfahrung.

Schlechte Erfahrungen gemacht? Na gut denn.
Meine Erfahrung entspricht deinem Gegenteil. aber muß mich nicht streiten.

[hoika]

Hallo,
unter c++ wird an den Methodennamen immer was drangehangen,
vielleicht ist es in c# ja auch so.

[Fritzew]

Du musst die Zielplattform im c# Projekt auf x86 setzten.

Die Declaration von

Delphi-Quellcode:

function ConvertToJson(pBytes: Pbyte; cBytes: Integer): string; stdcall; external 'MsgPack.Native.dll';

mit Rückgabe String wird auch nicht funktionieren.

Versuche es mit PWChar

[sh17]

Müsste es nicht

ConverToJson := GetProcAddress(dllhandle, 'ConvertToJson');

heißen?

Und evtl WideString anstatt String in der Deklaration der Funktion. Das mit 32bit und 64bit ist immer
etwas schwierig einzustellen in VS finde ich.

Nutzt Du DLLExport 1.7.4.? Al Beispiel mal mein Projekt

https://github.com/landrix/LibPhonenumber-for-Delphi

[venice2]

Zitat:

Das mit 32bit und 64bit ist immer
etwas schwierig einzustellen in VS finde ich.

Ist doch gut gelöst Debug\Release "COMBO" und dort Konfigurations-Manager starten.

bzgl. x86 und x64 ist so ein Problem.
Was bringt es wenn die Bibliothek RGiesecke.DllExport mit AnyCPU kompiliert wurde das beißt sich doch irgendwie.

Delphi DLL -> C# über DllImport ist kein Problem.
C# DLL über DllExport hingegen schon. (Leider)

bsp.

Code:

namespace CalcTest
{
    using System.Runtime.InteropServices;
    using RGiesecke.DllExport;

    public sealed class CalcTest
    {
        [DllExport(CallingConvention = CallingConvention.StdCall)]
        public static int Sum(int a, int b)
        {
            return a + b;
        }
    }

}

Delphi.

Delphi-Quellcode:

function Sum(a, b: integer): integer; stdcall; external 'Calctest.Net.dll';

Delphi Anwendung stürzt sofort ab.. läßt sich nicht starten!

Fehler!
Der Fehler 0xc000007b tritt typischerweise auf, wenn die 32-Bit-Version von Windows mit einem 64-Bit-Betriebssystem oder -Anwendungen verwechselt wurde.
Projekt ist aber x86 C# DLL ebenso jedoch RGiesecke.DllExport AnyCPU ..

EDIT:
RGiesecke.DllExport neu kompiliert 32Bit\x86 alle Frameworks 4.8 trotzdem selber Fehler.

[sh17]

Also mit der Lib von Robert Giesecke war irgend wann Ende im Gelände. Bin dann zu DLLExport gewechselt, was grob auf RGiesecke basiert, aber eine Neuentwicklung ist.

[venice2]

Zitat:

Zitat von sh17 (Beitrag 1504041)

Also mit der Lib von Robert Giesecke war irgend wann Ende im Gelände. Bin dann zu DLLExport gewechselt, was grob auf RGiesecke basiert, aber eine Neuentwicklung ist.

Ahh.. kann natürlich sein.

[venice2]

Damit funktioniert es nun.
Offline Package von DLLExport im Archiv.

genug damit gespielt.

Wenn er nun das als Beispiel nimmt und sein Projekt entsprechend anpaßt wird es wohl funktionieren.
DLLExport ist nötig.. Die neue (siehe Package) ohne geht es nicht!
Danke an @sh17 für die Info.

Werde die Anhänge später wieder löschen.

[Aviator]

Zitat:

Zitat von venice2 (Beitrag 1504044)

DLLExport ist nötig.. Die neue (siehe Package) ohne geht es nicht!

Was ich gestern die ganze Zeit gesagt habe. Aber du denkst ja immer direkt das jeder mit dir streiten will ... :roll:

[venice2]

Zitat:

Zitat von Aviator (Beitrag 1504057)

Zitat:

Zitat von venice2 (Beitrag 1504044)

DLLExport ist nötig.. Die neue (siehe Package) ohne geht es nicht!

Was ich gestern die ganze Zeit gesagt habe.

Kein LoadLibrary..

Zitat:

Aber du denkst ja immer direkt das jeder mit dir streiten will ... :roll:

Meine Jahre lange Erfahrung hier. Wäre oder ist nicht das erste mal.

Habe nur gute Erfahrung unter C# -> Delphi gemacht und umgekehrt weil alles soweit selbst geschrieben siehe meinen C# Wrapper für .NET für Bass_vis(Delphi DLL).
Du hattest halt schlechte Erfahrung und deshalb will ich nicht mit dir streiten.. Schrieb ich schon.

Problem gelöst Anhang gelöscht.

[MTranel]

Ich mach hier mal ganz kurz Werbung für mein NuGet Package was genau für diesen UseCase gebaut wurde.
Es arbeitet im Grunde genau wie UnmanagedExports nur das die Internals auf DNLib anstatt auf ildasm/ilasm basieren. Dadurch spart ihr euch das ab und zu die DLL baut aber keine Exports drin landen, weil euch irgendwelche Windows 10 SDKs fehlen. Und DLLExport ist zwar nett, aber mir passt das extra GUI zum exportieren im Nachhinein gar nicht.

https://github.com/MeikTranel/NXPorts

In den Samples ist das alles ganz gut dargestellt. Die Schnittstelle der Attribute ist quasi deckungsgleich mit der von RGiesecke und der Rest passiert automatisch.

[sh17]

Zitat:

Zitat von MTranel (Beitrag 1504080)

Ich mach hier mal ganz kurz Werbung für mein NuGet Package was genau für diesen UseCase gebaut wurde.
Es arbeitet im Grunde genau wie UnmanagedExports nur das die Internals auf DNLib anstatt auf ildasm/ilasm basieren. Dadurch spart ihr euch das ab und zu die DLL baut aber keine Exports drin landen, weil euch irgendwelche Windows 10 SDKs fehlen. Und DLLExport ist zwar nett, aber mir passt das extra GUI zum exportieren im Nachhinein gar nicht.

https://github.com/MeikTranel/NXPorts

In den Samples ist das alles ganz gut dargestellt. Die Schnittstelle der Attribute ist quasi deckungsgleich mit der von RGiesecke und der Rest passiert automatisch.

Cool, kannte ich noch nicht, gleich mal markiert.

[generic]

Du kannst in C# einen COM Server erstellen. Dessen interface exportierst du und importierst die TLB dann in Delphi.
Damit du den COM-Server nicht Registieren brauchst, nutzt du einfach Side-by-Side Konfiguration.

Das erspart viel fehleranfällige Schnittstellendefinitionen.