Nutzung .NET-DLLs in Delphi

leider kommen viele DLLs nur noch als .NET-Versionen und ohne exportiertes COM-Interface. So auch die (undokumentierten) SteuerDLLs für das LCP100. Ich habe mich heute den ganzen Tag durchs Internet gegoogled auf der Suche nach einem Weg, diese DLLs in TurboDelphi zu nutzen. Hier handelt es sich um .NET2.0 Libraries, sind also nicht mit TurboDelphi kompatibel (mal abgesehen davon, das dort der Componenteneditor kastriert wurde. TLibImp liefert mir nur die GUID, aber nicht die Objekte und Methoden.
Gibt es einen Weg, solche DLLs ohne teure Zusatzkomponenten zu verwenden?

Tommi

Ich fürchte nicht…

Dot.NET ansich erzeugt keinen Maschienencode wie es klassische compiler tun. Dot.NET ähnelt da eher HTML. Es wird formuliert was die exe tun soll und erst der passende Interpreter (vergl. Browser) des Betriebssystems führt diese Anweisungen aus. Die exe muss also vom „Dot.NET-Browser“ (dem Dot.NET Framework) ausgeführt werden. Dazu muss der natürlich auch installiert sein.

Was du jetzt wissen willst ist quasi wie man eine HTML-Seite mit nem Telnet Client öffnen kann. Das klingt jetzt vielleicht bescheuert aber soooo weit hergeholt ist das garnicht. Mein Delphi2009 kann das tatsächlich. Habs aber noch nicht ausprobiert. Mit TurboDelphi sehe ich da aber keine Chance, fürchte ich. Das ist so beschnitten, dass ich mir nicht vorstellen kann, dass ausgerechnet das funktioniert.

Wenn du willst kann ich das Montag aber mal ausprobieren.

Toni

Hallo Toni,

nach meinem Verständnis sind diese DLLs schon ausführbar, nur legen sie Ihre Informationen in der Assembly statt in der Registery ab. Im Internet werden verschiedene Wege der Nutzung beschrieben, aber am Ende laufen alle Vorschläge darauf hinaus, das ComInterface zu aktivieren. Man konnte übrigens .NET1.1-DLLs auch in Delphi(Vollversion) einbinden.Ein anderer Weg: Man kann sich ja mit ildasm den IL-Quelltext ausgeben lassen und dort die Änderungen machen und daraus wieder ein neues Binary erstellen. Nur das ist mir zu heikel, da ich momentan im Grunde gar nicht weiss, was ich dort ändere. Ich dachte, mittlerweile gibt es für Delphi schon eigene Standards dafür.

Schade, also doch selber programmieren.

Viele Grüße
Tommi

Du verwirrst mich…

Also ich arbeite mich grad in .NET ein, bin also absolut nich mit jedem Detail vertraut.

Die Assembly enthält den vorkompilierten Inline-Code. Das ist das was ich mit dem HTML-Beispiel verdeutlichen wollte. Bloß weil er zur Laufzeit compiliert werden muss heisst das für mich ja nicht, dass man ihn nicht ansprechen kann. Wie gesagt, mein Delphi2009 kann das wohl auch „einfach so“?!? Voraussetzung dürfte lediglich ein installiertes Framework mit der richtigen Version sein. Das sollte aber das kleinste Problem sein, oder?

Sicherlich kann man soeine DLL auch verändern nachdem er einmal erzeugt (vorkompiliert) wurde, aber davon würde ich ehrlich gesagt auch die Finger lassen. Da müsste man schon ein ziemlich gutes tutorial haben und wirklich wissen was man tut. Ich würds mir jedenfalls erstmal nicht zutrauen.

Aber dass irgendwas in der Registry abgelegt wird hab ich noch nie gehört. Weder bei .NET noch bei dem guten, alten Maschienencode.:confused:

Ich denke auch, dass sich schon andere mit diesem Problem auseinander gesetzt haben. Aber als TurboDelphi-User hast du ja noch ganz andere Einschränkungen. Ich kann mir als gut vorstellen, dass es zwar einen standardtisierten Weg gibt, der dir aber verwährt bleibt. Der Assembly-Import meines Delphi2009 könnte dieser Weg sein. Aber wie gesagt, ich könnte es frühestens Montag testen.

Toni

Hallo Tomi.

Aber dass irgendwas in der Registry abgelegt wird hab ich noch nie gehört. Weder bei .NET noch bei dem guten, alten Maschienencode.

Ich meinte damit die Objekt(Klassen)-Informationen(TypLibraries), die man für COM-Zugriffe braucht und die sonst unter HKCR{GUID} abgelegt werden.

Viele Grüße
Tommi

Ich wüsste keinen Weg ausser in .NET einen Wrapper für diese Funktionen zuschreiben. Elegant ist diese Lösung natürlich nicht.

paresy

So, ich hab mal ein bissel herumgespielt und bin an einem Punkt angelangt, an dem mir das knowhow fehlt.

Ich hab die Eq3.LCP100.dll mal in mein Delphi importiert und bekomme eine Typelibrary (sowiso_TLB.pas) erzeugt. Fein, dacht ich mir, damit kennste dich ja aus. Doch - Hoppla - die ist fast vollkommen leer. Ohne Kommentare steht etwa Folgendes drin:


const
  // Haupt- und Nebenversionen der Typbibliothek
  Eq3_LCP100MajorVersion = 1;
  Eq3_LCP100MinorVersion = 0;

  LIBID_Eq3_LCP100: TGUID = '{DE838298-63AF-453F-AC8C-A3C47F7AB4FB}';

implementation

uses ComObj;

end.

Nagut… Das riecht ja nach nem COM-Object. Wär ja nicht tragisch. Ich also ein COM-Object versucht zu erzeugen anhand der LIBID. Resultat:


---------------------------
Project1
---------------------------
Klasse nicht registriert, ClassID: {DE838298-63AF-453F-AC8C-A3C47F7AB4FB}.
---------------------------
OK   
---------------------------

Nagut… Wenn das Ding schon LibID heisst und nicht ClassID oder ObjID… Vielleicht der falsche Weg. Oder muss ich ne Assembly erst irgendwo dem OS bekannt machen wie man es auch bei herkömmlichen DLLs macht? RegAsm.exe? Oder was wäre nun der nächste Schritt? Jemand ne Idee?

Toni

Hallo Toni,

an dem Punkt war ich auch angelangt. Das Problem ist, das in der Assembly-Definition der Punkt ComVisible auf false steht.
Man kann das sogar ändern, indem man mit ildasm den Quellcode erzeugt, die notwendigen Einträge ändert und wieder neu compiliert(ilasm).
Wie das geht, ist auch im Internet zu finden, hier hat sogar jemand ein Programm dafür geschrieben. Aber das ist mir dann doch zu blöd. Da mache ich mir (wie auch Paresy vorgeschlagen hat) gleich in C# eine neue DLL mit den richtigen Funktionen, wie sie auch in der Demo.exe als Kommandos benutzt werden, mache sie exportierbar und habe nicht mal in fremden Code rumgefummelt.
BTW. Wenn Du an der Baustelle LCP100-Modul auch dran bist, brauche ich mich darin nicht noch mehr reinwuseln, da das ganze .Net gedöns doch eine komplett andere Welt ist.

Tommi

Ja, den Beitrag auf codeproject hatte ich gelesen. Sehe ich genauso wie du.

Tja, so richtig „dran“ bin ich nicht. Aber ich find das Thema spannend. Zumal ich mich beruflich eh in .Net einarbeiten muss.

Ich hab mich auch gefragt ob es nicht machbar ist das Protokoll „einfach“ direkt in Delphi nachzubauen. Eine Kommunikation über ne virtuelle serielle Schnittstelle kann ja so schlimm nicht sein. :confused: Ist natürlich ein bissi reverse engeneering gefragt.

Toni

Hallo Toni,
Das Arbeiten mit einem VCP ist nichts besonderes. Das habe ich bei meinen letzten Projekten schon gemacht. Der WDE1 hat den gleichen Chip drin. SerialPortModul als parent nehmen und gut ist.
Man muss beim LCP100 auch noch nichteinmal gross „reverse Enegeneering“ machen, da das Protokoll dokumentiert ist (ja, oh Wunder! ;)). Man braucht lediglich etwas mehr Zeit, die CRC-Routine, die Image-Transformation und die Aufteilung auf die Pages nachzubauen.

Tommi

Äh… Wo finde ich denn diese Doku? Im download von der Webseite war sie nicht dabei, oder bin ich jetzt doof?!? :eek:

Toni

Die ist in der gedruckten Beschreibung dabei, wenn man sich das Teil kauft, bzw. auch im ELV-Journal 2/2009 S.32/33.

Tommi

Oha… Das ist so wenig, dass ichs echt übersehen hab. :smiley:

Ich hab schon mit CRCs gearbeitet, aber da kommt echt nur Müll bei raus. Was genau soll man mit $8005 und der $FFFF machen? :confused: Irgendwie steh ich auf dem Schlauch. Hab auch irgendwie keine Ruhe dabei heute…

ich schicke ne Versionsabfrage (v).

und der Vogel antwortet

Ich weiss auch, das da wohl die Versionsnummer 1.2 drin stehen muss, aber irgendwie… :confused:

Toni

Im Internet finden sich auch Hinweise, das die CRC-Berechnung nicht so funktioniert, wie sie der Normalbürger anhand der Beschreibung interpretieren würde. Deshalb wollte ich mir den Zirkus auch sparen und die mitgelieferten DLLs als Blackbox nutzen.

Tommi

Kleines Update:

Hab hab grade einen (angeblich) funktionierenden C++ Code bekommen. Werd mir den die Tage mal anschauen. Bin schon ganz gespannt. :D:cool:

Toni