Delphi-Dlls in C# nutzen

Hallo zusammen

Ich möchte von Delphi auf C# umsteigen habe aber einigen Delphi-Code, den ich nicht neu schreiben möchte.

Weiss jemand von euch vielleicht, wie man Routinen aus einer Delphi-dll
in C# aufrufen kann und was man sonst noch beachten sollte?
Super wäre auch, wenn mir vielleicht jemand einen Link zu einem oder mehreren Beispielen geben kann.

Vielen Dank für Eure Tipps

Geri

Meine Delphi Version ist die Version 7.0

hast du schon malmit DllImportAtributte versucht?

Ist auf jeden Fall nicht gerade einfach, besonders nicht als .Net-Anfänger. Sind Delphi-Dlls eigentlich kompatibel mit COM? Wenn ja, kannst du mit tlbimp.exe .Net-Wrapper-Dlls generieren lassen.

Ansonsten bleibt nur, mit extern-Methoden und DllImport die Wrapper selbst zu schreiben. Such' im Board mal nach "Platform Invoke" oder PInvoke.

Gruss
Pulpapex

kann leider nicht sagen wie es geht, aber ich weiss das es relativ simpel bzw unaufwendig gehen muss, da z.b. die Indyokomponentensammlung komplett in Delphi geschrieben sind und auch in der .net Variante für C# noch als Delphikompilierung vorliegen. Vielleicht findest du da ja einen Hinweis auf die konvertierung.

Hallo

Vielen Dank vererst einaml für die Tipps. Ich werde eure Infos nutzen um weiter zu recherchieren.

So wie sich eure Antworten anhören, gibt es mehrere Wege.
Schön wäre es, falls mir jemand vielleicht anhand eines Beispiels aufzeigen könnte wie man die Sache angeht.

Vielen Dank

Geri

Achtung: Delphi hat eigene String-Typen, die NICHT kompatibel mit .NET sind. Wenn man allerdings DLLs für Delphi erstellt, dann achtet man bereits auf sowas und verwendet entsprechende Typen (WCHAR, PCHAR, etc.).

Ansonsten sind COM und DLLs nicht "kompatibel". COM steht für Komponenten und haben insofern was mit DLLs zu tun, als dass COM-Objekte in Form von DLLs vorliegen.

COM-Objekte werden mittels COM-Interop automatisch in .NET eingebunden (einfach Referenzieren). COM-Objekte definieren nicht nur Methoden sondern auch Typen. DLLs müssen händisch via DllImport eingebunden werden. Ebenso muss man verwendete Typen per Hand definieren.

Hallo Sven

Wärst du bitte so nett und forwardest mir ein einfaches Beispiel, in dem aufgezeigt wird, wie man so ein Problem mit COM löst.

Vielen Dank für Deine Mühe
Geri

Das ist leider nicht so einfach. Ich kanns vielleicht mal grundsätzlich erklären:

Eine DLL ist erstmal nichts weiter als eine Sammlung von Funktionen und/oder Prozeduren. Klassen sind erstmal nicht.

Funktionen dieser DLLs kann man einfach mit

[php]
[DllImport("meineDLL.dll")]
private static extern void meineProzedur();
[/php]

einbinden.

Wenn du mit COM arbeiten willst, dann musst du diese lose Sammlung von Funktion in einen objektorientierten Rahmen giessen (also ne Klasse erzeugen und die Funktionen als statische Member deklarieren).

Jetzt kommt die harte Nummer: Du musst aus dieser Klasse ein COM-Objekt machen (da gibts dann noch viele Varianten von!). Dies ist leider sehr kompliziert und wird zumindest bei Visual Studio mit speziellen Wizards unterstützt, die mehrere 100 Zeilen Code generieren, die so ein COM-Objekt grundsätzlich benötigt. Dort können dann auch Typen definiert werden, die in den Interfaces benötigt werden.

Dieses COM-Objekt in Form einer DLL muss dann mittels "regserv" (Tool von Windows) im System "registriert" werden und steht dann allen Anwendungen im System (oder darüber hinaus) zur Verfügung.

Um dieses Objekt nun von einer .NET-Anwendung zu nutzen, muss du die Komponente in die Registerkarte der Komponenten installieren. Du findest die Komponente dann unter der Reiterkarte "COM".

Dann aufs Fenster ziehen und fertig. Jetzt nur noch die Funktionen aufrufen.

Meine Empfehlung: Ein COM-Objekt bauen ist die hohe Schule der Windows-Programmierung, benötigt eine Menge Wissen und sollte von der Entwicklungsumgebung direkt mit Wizards unterstützt werden.

Mit einfachen DLLs zu arbeiten benötigt zwar ein wenig händischen Aufwand (eben DLLImport und ggf. ein paar Typdefinitionen) für den Import, ist aber VIEL einfacher und leichter nachzuvollziehen. Wenn es geht, nimm normale DLLs.

COM-Objekte haben den Vorteil, dass sie so mächtig sind, dass sie praktisch mit jeder Entwicklungsumgebung mit dem eigenen Komponentenmodell in Einklang zu bringen sind. Daher sind sie "interoperabel". Active-X-Controls (so heissen COM-Objekte, die als Oberflächenobjekte definiert sind) lassen sich unter C++, Delphi oder .NET nutzen, und das meist ohne dass der User merkt, dass es sich um ein COM-Objekt handelt. Die Entwicklungsumgebungen bauen bei Bedarf einfach sogenannte "Wrapper", die total verschleiern, um was für eine Komponente es sich hier handelt.

Hersteller, die sich nicht die Mühe machen wollen, ihren neuen super-tollen Reportgenerator einmal als Delphi-, .NET- oder Was-auch-immer-Variante zu bauen, die machen einfach ein Active-X und fertig ist.

Nachteil von COM: Die Installation der Anwendung ist komplizierter. Es reicht nicht einfach die DLL in der sich die Komponente befindet mitzukopieren, sondern die Registrierung mit "regserv" ist zwingend notwendig. Um ein Installationstool (oder zumindest Batch) kommst du dann nicht herum.

Hallo Svenson

Super, vielen Dank für deine ausführliche Beschreibung. Ich habe inzwischen den Ansatz der DLL gewählt, und es funktioniert einwandfrei. Ich glaube, es gibt sogar im iNet ein Programm, welches automatisch sogenannte Wrapper erzeugt. Dann wird der Code direkt in das EXE-File eingebunden und man benötigt die DLL nicht mehr.

Ein Problem. welches s.w. auch mit COM übrig bleibt ist, wenn C# bestimmte Klassen nicht bekannt sind. Beispielsweise, gibt es in Delphi eine TStringList-Klasse. Ob sie die die dann exportieren lässt..?

Ein weiterer Ansatz könnte auch sein, den Delphi-Code zu Konvertierten.
In einiger Zeit zum Editieren hat man dann auch den C#-Code. Dann schleppt man wenigstens keine Altlasten mehr mit.

Jedenfalls vielen Dank für die vielen Tipps, ich denke so kann ich weiter machen.

Freundliche Grüsse

Gerhard

Original von GeriB
Ein Problem. welches s.w. auch mit COM übrig bleibt ist, wenn C# bestimmte Klassen nicht bekannt sind. Beispielsweise, gibt es in Delphi eine TStringList-Klasse. Ob sie die die dann exportieren lässt..?
Gerhard

Hier wirst du mit hoher Wahrscheinlichkeit Trauer tragen. Man muss aber auch sagen: Wer eine Delphi-DLL baut, die von anderen Programmiersprachen genutzt werden sollen, der sollte keine speziellen Typen nutzen. Hier hätte es ein Array of String sein müssen. Zur Not musst du die DLL an diesen Stellen modifizieren.

TStringList ist nunmal Delphi-spezifisch und das wird sie auch bleiben.

Generell gilt bei Interop-DLLs:

* keine Collections, nur Array s(also auch keine TStringList)
* Win32-String-Typen (Achtung: Hier gibts ASCII/ANSI und verschiedene Unicodes!)
* keine optionalen Parameter
* keine Spezial-Typen (z.B. decimal, bignum, etc.)
* Namensgebung beachten (Groß/Klein, Max-Länge)

Am besten Aufruf-Typ stdcall, obwohl .NET eigentlich mit allem zurecht kommt.

Hallo Svenson

Besten Dank nochmals für die vielen kompetenen Infos!! Werde künftig daran denken oder vielleicht bin ich das Problem eh bald los🙂

Beste Grüsse
Gerhard