C# DLL in Delphi nutzen

[venice2]

Zitat von Aviator:

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]

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

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.
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.