Moin,

welches Forum eignet sich mehr als dieses bei meinem jetzigen Problem xD

Also ich habe eine Dll in C# geschrieben, diese soll in Delphi verwendet werden, funktioniert auch (bedingt).
Nun zu meiner Frage/Anliegen:
Die Dll soll einige Funktionen ausführen, die relative simpel aufgebaut sind. Wenn ich die Dll in C# verwende kommt es zu keinem Fehler! Doch in Delphi kommt es immer zu einer Fehlermeldung(leider bekomme ich nur die Fehlermeldung, habe kein zugriff auf den Code!).
Wenn die Dll in Delphi benutzt wird funktioniert eine Methode ohne Probleme, doch wenn nach der Methode eine weitere Methode aus der Dll verwendet wird, kommt eine Fehlermeldung:


Nun ich denke mir das es sich hierbei um ein Fehler handelt, der besagt das irgend ein Objekt nicht benutzt werden kann, ich weiß nicht aus welchen gründen, den das Objekt ist in der Dll eine Globale Variable.
Das komische ist, dass diese Variable in den beiden Methoden verwendet wird, bei der ersten kommt es zu keinem Problem und bei der zweiten schon...

Nun weiß ich nicht wie Delphi arbeitet, doch kann es sein, dass das Objekt in Delphi nach der ersten Benutzung gelöscht oder genullt wird ?

Diesen merkwürdigen Fehler kann ich in C# nicht nachstellen, da er sogar 3 Methoden hintereinander ausführen kann, wo das selbe Objekt enthalten ist.

Hatte jemand mit einem solchen Problem schon mal zutun? Ich freue mich über jeden Anhaltspunkt.

Liebe Grüße

Zitat:

(leider bekomme ich nur die Fehlermeldung, habe kein zugriff auf den Code!).

Auf dem Niveau ist dann wohl kaum zu helfen Wenn deine dll im managed Umfeld funktioniert liegt das Problem in der Art wie die Assembly aufgerufen wird. Ohne irgendwelche Infos wie das passiert kann man nur mit den Schultern zucken.
Weißt du zumindest ob das via Com Interop ist, Reverse P/Invoke, irgendein DllExport gebastel auf der managed Seite oder was auch immer ist?

Zitat:

Nun weiß ich nicht wie Delphi arbeitet, doch kann es sein, dass das Objekt in Delphi nach der ersten Benutzung gelöscht oder genullt wird ?

Dein Object ist managed code, Delphi ist unamanged code und hat keinerlei direkten Zugriff auf den managed Heap. Also nein. Wenn es beim Interop Probleme gibt liegt das in der Art der Interop.

Sicherlich ist in deinem Delphi-Programm ein kleiner Fehler bei der Benutzung der DLL drin. Wenn du den Quellcode eines kleinen Testprogramms postest, können wir ja mal drüber schauen wo das Problem liegt.

Primär macht Delphi mit Daten, die nicht innerhalb der Herrschaft des Compilers liegen (was folglich DLL, OCX und wasauchimmer einschließt) gar nichts. Kann es auch nicht, hat ja keine Ahnung, was sich dahinter verbirgt.

Das problem wird innerhalb der Delphi-Routinen zu suchen sein, die die DLL-Daten "begrabbeln". Genullt wird jedenfalls nix von Delphiseite, es sei denn, man programmiert es so (FreeAndNil ist so ein Kandidat).

Hallo Ralf Jansen,

Ralf Jansen hat folgendes geschrieben :

Auf dem Niveau ist dann wohl kaum zu helfen Wenn deine dll im managed Umfeld funktioniert liegt das Problem in der Art wie die Assembly aufgerufen wird. Ohne irgendwelche Infos wie das passiert kann man nur mit den Schultern zucken.

Tut mir leid, aber ich habe leider echt kein Zugriff auf den Delphi part, denn ich habe nur die DLL entwickelt und ein Kumpel von mir benutzt die Dll in Delphi.
Und mit managed Umfeld, meinst du sicherlich die Umgebung wo die Dll geschaffen wurde oder?

Ralf Jansen hat folgendes geschrieben :

Weißt du zumindest ob das via Com Interop ist, Reverse P/Invoke, irgendein DllExport gebastel auf der managed Seite oder was auch immer ist?

Willst du von mir wissen ob ich in meiner Dll auf andere Dll zugreife und benutze?
Wenn ja, ich benutze andere DLL's die aber mein Kumpel mit in seiner Delphi Anwendung tut.

Ralf Jansen hat folgendes geschrieben :

Dein Object ist managed code, Delphi ist unamanged code und hat keinerlei direkten Zugriff auf den managed Heap. Also nein. Wenn es beim Interop Probleme gibt liegt das in der Art der Interop.

Was heißt den nun hier managed Code und unmanaged Code ?

Hallo baumina

baumina hat folgendes geschrieben :

Sicherlich ist in deinem Delphi-Programm ein kleiner Fehler bei der Benutzung der DLL drin. Wenn du den Quellcode eines kleinen Testprogramms postest, können wir ja mal drüber schauen wo das Problem liegt.

Leider besitze ich den Delphi part nicht

Hallo OlafSt

OlafSt hat folgendes geschrieben :

Das problem wird innerhalb der Delphi-Routinen zu suchen sein, die die DLL-Daten "begrabbeln".

Kann man dies irgendwo sehen, bei Delphi?

Danke für eure Antworten

LG

Ohne Delphi(code) kommst du hier kein Stück weiter, da muss wohl dein Kumpel mal ran.

Zitat:

Willst du von mir wissen ob ich in meiner Dll auf andere Dll zugreife und benutze? Wenn ja, ich benutze andere DLL's die aber mein Kumpel mit in seiner Delphi Anwendung tut.

Nein wollte ich nicht.
Eine C# Assembly ist keine normale Dll. Sie ist zwingend abhängig von .Net und muß in der Laufzeitumgebung von .Net ausgeführt werden. Solchen Code von C# oder irgendeiner anderen .net Sprache nennt man managed (weil er eben unter der Aufsicht der .Net Runtime, die managed das sozusagen, läuft). Delphi weiß davon rein gar nix und kann die erstmal so nicht verwenden. Damit man die 2 Welten zusammenbringt muß man irgendwas aktiv tun, es reichen nicht einfach Delphi übliche dll Verwendungsverfahren. Ohne zu wissen was ihr da macht können wir nicht erraten was da denn schiefgeht.

Zitat:

Was heißt den nun hier managed Code und unmanaged Code ?

Managed Code - Code der üblicherweise im Rahmen einer bestimmten Runtime ausgeführt werden muß. Heißt es ist kein Maschinencode der direkt auf der CPU ausgeführt wird sondern erst von dieser speziellen Runtime zur Laufzeit(näherungsweise) für die CPU übersetzt wird. Heißt eine in C# kompilierte Dll enthält keinen Code den der Prozessor direkt ausführen könnte oder den ein Stück Software der nicht aus der .Net Welt stammt einfach so benutzen könnte. Neben .Net gilt das genauso für Java.
Unmanaged Code - Code der direkt in Maschinen verständlichen (CPU abhängigen) Code übersetzt wurde. Klassische Sprachen und deren Compiler (c, c++, Delphi) erzeugen solchen Code.
Beide Welten sind erstmal zueinander inkompatibel udn man muß irgendwas spezielles tun um die Grenze zu überwinden.

Vegeto hat folgendes geschrieben :

Hallo OlafSt OlafSt hat folgendes geschrieben : Das problem wird innerhalb der Delphi-Routinen zu suchen sein, die die DLL-Daten "begrabbeln". Kann man dies irgendwo sehen, bei Delphi?

Da Delphi nativen Code erzeugt (im gegensatz zu .NET, wo eine Art Zwischencode erzeugt wird), läßt sich ohne Quelltext hier rein gar nix sehen

Mein Tip: Wenn der "Kumpel" sich so quer stellt, das er die paar Zeilen Code nicht zeigen will, würde ich dazu raten, das er die Funktionalität deiner C#-DLL schlicht mit Delphi nachprogrammiert. Dann hat er diese Probleme nicht und darf weiter vor sich hin frickeln
Das Thema "native EXE mit .NET-DLL verheiraten" ist alles andere, nur nicht trivial. Eine simple Import-Unit und ein paar "external 'bla.dll'" reichen hier bei weitem nicht aus. Ohne ein ausgesprochen gesundes Maß an Kenntnissen über COM wird das nix. Das gilt übrigens auch für die .NET-Seite, wenn auch nicht in ganz so detailliertem Maße.

Hallo baumina,
ich baue nun in mein DLL eine Art Debugfunktion.

Hallo Ralf Jansen,
Danke für deine Erklärung, hast mir Licht in diese Dunkele Höhle gebracht
Doch auf dem Computer ist .Net 4.5 Installiert, ich versuche es nun mit einer Debugfunktion.

Hallo OlafSt,
Danke für dein Tipp.


Danke an euch Drei, habt mir sehr geholfen.

Liebe grüße

Hallo ich bin es nochmal.

Ich habe mir das ganze etwas leichter vorgestellt.
ich habe in meiner Dll, mittels StreamWriter-Klasse ein Objekt erzeugt und schreibe in der Problem Methode immer was in ein Log-Datei. Mit SW.WriteLine("Hier befindet sich der Code");
Doch irgendwie wird keine Log-Datei erzeugt. Woran liegt das? Ist es nicht möglich aus einer DLL heraus ein LogFile zuschreiben?

Lg

Natürlich ist das möglich

Aber nicht ganz so trivial. Du brauchst Schreibrechte in dem Verzeichnis, in dem das Logfile landet. Solltest du vorhaben, das Logfile in ein Hauptverzeichnis schreiben zu wollen (C:\), dann sogar Administrator-Rechte, inklusive UAC-Warndialog etc.

Für einfache Quick-n-Dirty-Logs würde ich erstmal das Temp-Verzeichnis nehmen, womöglich brauchts dafür nicht mal richtige Zugriffsrechte. Sollen die Logs später längerfristig erhalten bleiben, würde ich das dann woanders hinpacken.

Hallo OlafSt,

Danke für deine Antwort, die Logdatei lege ich auf ein Netzwerklaufwerk ab, aber es funktioniert einfach nicht. Ich weiß nicht mehr weiter.
Ich habe die Dll bei mir probiert in der C# Umgebung da funktioniert alles Tip Top.

Ich habe sogar versucht aus der Dll MessageBoxen auszugeben auch diese kamen bei meinem Kumpel nicht aus. Ich glaube ich habe irgendwo einen kleinen Denkfehler, aber ich finde ihn einfach nicht.

Ich denke auch nicht das es Rechte Probleme sind, denn mein Kumpel hat non-plus-Ultra Adminrechte xD

Muss ich die GUID der DLL immer neu vergeben, wenn ich die Funktionen Anpasse?

Bei der Schnittstelle, mit dem selben Header nur einen anderen GUID-String, denn ich weiß wenn beide GUID-Strings gleich sind kommt es zu einem Fehler bei meinem Kumpel.

Oder muss ich der Dll immer nach Neu Erstellung eine neue Versionsnr. geben?

MfG

Jetzt wissen wir zumindest das ihr versucht COM zu benutzen. Die Frage hast du ja bisher angestrengt versucht nicht zu beantworten

Zitat:

Oder muss ich der Dll immer nach Neu Erstellung eine neue Versionsnr. geben?

COM Dlls mußt mam im System registrieren(ich vermute mal schwer ihr benutzt kein Registry Free COM). Wenn du die Dlls veränderst, Versionnummer, Guid, Lagerort, Interface dann mußt du die neu registrieren. Solange sich davon nichts ändert funktioniert die auch weiterhin.

Wenn die bei dir in C# funktioniert hast du die Dll denn auch per COM benutzt? Wenn du dir einfach referenzierst hast dann hat die Art der Benutzung in C++ und C# nichts miteinander zu tun und ist nicht vergleichbar.

Ralf Jansen hat folgendes geschrieben :

Jetzt wissen wir zumindest das ihr versucht COM zu benutzen. Die Frage hast du ja bisher angestrengt versucht nicht zu beantworten

Sorry hätte ich im ersten Post erwähnen müssen.

Ralf Jansen hat folgendes geschrieben :

COM Dlls mußt mam im System registrieren(ich vermute mal schwer ihr benutzt kein Registry Free COM). Wenn du die Dlls veränderst, Versionnummer, Guid, Lagerort, Interface dann mußt du die neu registrieren. Solange sich davon nichts ändert funktioniert die auch weiterhin.

Die DLL wird von meinem Kumpel nach jeder neuen Erstellung neu Registriert, dies macht er über cmd.

Ralf Jansen hat folgendes geschrieben :

Wenn die bei dir in C# funktioniert hast du die Dll denn auch per COM benutzt? Wenn du dir einfach referenzierst hast dann hat die Art der Benutzung in C++ und C# nichts miteinander zu tun und ist nicht vergleichbar.

Da hast du recht ich referenziere sie nur, ich Registriert nichts.


Aber ich weiß nicht warum, aber der macht nicht, dass was im Code steht.
Neben der Logfunktion (Textdatei erstellen, was die einzelnen Schritte festhält), habe ich auch TextBoxen ausgegeben, doch das geschieht bei meinem Kumpel auch nicht.

Die letzte Möglichkeit die ich jetzt habe, ich vergebe der Klasse (nicht dem Interface) eine neue GUID und ich Signiere sie neu (neue .snk erstellen).

Sonst weiß ich nicht mehr weiter.

Falls ihr noch weitere Anregungen oder Tipps habt, nehme ich gerne an.

LG

Ja, ich hätte noch eine Anregung. Dein Kumpel könnte eine Runde google quälen mit den Suchbegriffen "Delphi .NET DLL benutzen". Das ist nämlich gar nicht so einfach und auf keinen Fall mit einem Dreizeiler gemacht.

Und dann wären da noch die Anregungen, die keiner hören will: Kumpel schreibt um nach C#, Du schreibst um nach Delphi (also nur eine Art Compiler benutzen), das ganze vergessen, wenn eine Seite sich standhaft weigert, was dazuzulernen

Zitat:

Die DLL wird von meinem Kumpel nach jeder neuen Erstellung neu Registriert, dies macht er über cmd.

Mit Regasm? Und dann auch mit der richtigen Version von Regasm (richtiges Framework und richtige Bittigkeit)?