Wie ein array of record von C# dll mit COM an Delphi übergeben?

[Elvis]

Ich glaube nicht dass .net core überhaupt die Sachen hat, die sie damals für managed C++ und später C++/CLI eingebaut haben.
und das ist ja was ich da ausgenutzt habe

[jaenicke]

Doch, .NET Core wird offiziell unterstützt. Es gibt auch keine Fehler, wenn ich ein solches Projekt kompiliere und die Exporte werden auch gefunden, aber es knallt, wenn ich diese aufrufe. Aber das muss ich mir noch in Ruhe anschauen. Ich verwende Com-Interfaces via Marshalling mit C# Objekten und vielleicht gibt es die Probleme auch nur dabei.

[Thomasl]

Ich verwende auch eine selbst erstelle c# DLL in Delphi.
Schon länger, also ohne Nuget Tools/Hilfen.
Nur einfache Datentypen.

Aber ihr schreibt Debuggen geht nicht.
Das Debuggen geht ganz normal in 32 und 64bit

Was ich noch nicht probiert habe sind C# DLL‘s die nicht Registriert werden müssen

[jaenicke]

Zitat:

Zitat von Thomasl (Beitrag 1524353)

Was ich noch nicht probiert habe sind C# DLL‘s die nicht Registriert werden müssen

Darum geht es ja. Klar kann man eine C# Assembly auch via COM importieren. Aber dann muss sie eben auch registriert werden, während man eine Assembly mit nativen exportierten Funktionen einfach so nutzen kann. Und wie geschrieben, das von mir veröffentlichte Projekt erlaubt den einfachen generischen Austausch von Interfaces zwischen den beiden Seiten. Das macht das ganze sehr flexibel.

[Elvis]

Zitat:

Zitat von jaenicke (Beitrag 1524352)

Doch, .NET Core wird offiziell unterstützt. Es gibt auch keine Fehler, wenn ich ein solches Projekt kompiliere und die Exporte werden auch gefunden, aber es knallt, wenn ich diese aufrufe. Aber das muss ich mir noch in Ruhe anschauen. Ich verwende Com-Interfaces via Marshalling mit C# Objekten und vielleicht gibt es die Probleme auch nur dabei.

Hmm, bin da schon länger raus.
Hatte es damals hauptsächlich gemacht, weil Delphi.net es konnte und Chrome (später Oxygene) konnte es nicht.
Und weil ich zu oft auf stackoverflow gelesen hatte dass es unmöglich ist. :-D

Das Problem mit netcore ist, dass es AFAIR keine wirklichen DLLs baut, nur Assemblies.
Und selbst wenn, dann bin mir nicht sicher dass die runtime automatisch thunks erzeugt, die vom extern call in den managed call übersetzen und sicherstellen dass die shared runtime in den Prozess geladen wird.

Das ist alles super kompliziert und MS hat das nur wegen C++/cli gebaut. Weil es dann schon da war, haben sie es bis 4.8 drin gelassen aber nie wieder angefasst.

netcore ist von der runtime eher Mono, das hatte das nie in dem Umfang.

kann aber auch falsch liegen, müsste dafür erst specs und dotnet runtime code durchwühlen…

[jaenicke]

Vielen Dank für deine Antwort. Ich habe mir das nun noch einmal angeschaut. Es sah schon so aus, als ob das Richtige passiert. Es wird in der Execution Engine GetTargetForVTableEntry und darin CorDllMainWorkerForThunk aufgerufen. Dann geht es in die CLR, aber dort kommt dann eine externe Exception, aber erst, wenn, soweit ich das verstanden habe, schon auf das Objekt zugegriffen werden soll. Daraufhin habe ich ein wenig gesucht.

Lösung:
Wenn man DllExport installiert oder die Batchdatei DllExport.bat im Projektverzeichnis manuell aufruft, gibt es unten rechts die Option "Use our IL Assembler. Try to fix 0x13 / 0x11 opcodes.", welche "Rebase System.Object: System.Runtime > mscorlib" freischaltet. Beide müssen gesetzt werden, dann klappt es auch z.B. mit .NET 6.0.

Ich werde nun eine entsprechende Dokumentation zu meinem AppCentral-Projekt erstellen, die C#-Seite komplett implementieren, dann sollte das auf einem guten Weg sein.

Ich habe übrigens nun auch eine passende Java-Implementierung angefangen, so dass man auch von dort eine solche C#-DLL oder auch eine Delphi-DLL einbinden kann. Das sieht aber auch nicht ganz so einfach aus... aber mal schauen. :-D