[Gelöst] DLL-Probleme

[Knuddlbaer]

Imports metadata into a program compiled with /clr.

#using file [as_friend]

Parameters
file
An MSIL .dll, .exe, .netmodule, or .obj. For example,

#using <MyComponent.dll>

Das was Du da hast ist , vom reinen ansehen her, KEINE managed DLL. Das wird so also nichts werden. In einer einfachen native dll wirst Du die dem Client die Funktionen über einen Header bekannt machen müssen und gegen eine lib linken müssen.

Alternativ kannst Du einfach eine Managed DLL erstellen. Klassen die innerhalb dieser DLL Public sind, können von aussen gesehen werden.

namespace Geraete
{
	public ref class GeraeteDetails 
         {
              public methode() { dosomething(); }
         };

Die Frage ist also: Was willst Du ?

[NewtonsLaw]

Knuddlbaer schrieb:

Die Frage ist also: Was willst Du ?

Ich will eigentlich nur aus den bisherigen h- und cpp-Files, die meine derzeitigen Funktionen/Klasen usw. enthalten, ne DLL erstellen. Die Funktionen und Klassen sind alle unmanaged, deswegen will ich nicht (unbedingt) ne neue DLL mit ner managed Klasse erstellen...
Am liebsten eben die derzeitigen Dateien nur umkopieren, DLL erstellen, einbinden, fertig....

Knuddlbaer schrieb:

Das wird so also nichts werden. In einer einfachen native dll wirst Du die dem Client die Funktionen über einen Header bekannt machen müssen und gegen eine lib linken müssen.

Soll also heissen, ich muss die h-Datei, die in meiner DLL drinsteckt, ebenfalls ins Arbeitsverzeichnis packen und die inkludieren?????

[Knuddlbaer]

Woher soll die Anwendung denn sonst die Deklarationen für die Funktionen, die in der DLL stecken herbekommen ?

[Menne]

Knuddlbaer schrieb:

Woher soll die Anwendung denn sonst die Deklarationen für die Funktionen, die in der DLL stecken herbekommen ?

Aus der LIB die dem Linker bekannt gemacht werden muss.

[asdasdasd]

Jup - und den Header brauchst Du für den Compiler , der will ja ne Deklaration sehen.

[NewtonsLaw]

OK OK.... Glaub jetzt hab ichs gerafft. Dachte immer die DLL bringt sozusagen alles mit. Is aber wohl nicht so!

Wenn ich die Header inkludiere, gehts, Danke für die Tipps!
Aber noch ne andre Frage: Wenn ich ne Managed-DLL erstell (also public ref class oder sowas in der Art), dann kann ich das ja nur unter Visual 2005 weiterverwenden? Oder? Heisst also, wenn ich die Managed-DLL an nen Kollegen weitergeb, der nur natives C++ betreibt mit ner alten Visual-Version, der kann dann die Funktionen nicht nutzen, weil er mit der Header nix anfangen kann (wegen dem public ref class, was es in der alten Version noch nicht gibt)? Richtig oder hab ich da wieder mal nen Denkfehler drin?

Trotzdem schon mal Danke an euch alle!

[Menne]

Kein Programmierer wird seine DLL Header mitgeben.
Da kann ihn ja jeder in die Karten gucken.
Wobei ich auch noch nie eine Header für die DLL's mitbekommen habe.
Die Deklarationen sind aus der LIB zu erkennen.

[Jochen Kalmbach]

Bei MS Compilern wird für die Benutzung einer DLL eine LIB- und eine H-Datei benötigt. (Punkt)

Es sei denn Du benutzt die DLL via LoadLibrary/GetProcAddress

[NewtonsLaw]

Ich bins mal wieder!

Hab jetzt den ganzen Kram in DLL's gepackt, Projekt mit den DLLs zusammengebastelt, und: NIX funktioniert!!

So, jetzt mal wieder ruhig!
Also DLL erstellen usw. klappt alles. Einbinden der Header usw. auch, meine Klassen und Namespaces sind meinem Projekt bekannt... Alles wunderbar. Allerdings bekomm ich dauernd den Linkerfehler LNK2028. Aus MSDN werd ich auch nicht schlau, da steht:

Wenn eine systemeigene Funktion in ein reines Abbild importiert wird, unterscheiden sich die impliziten Aufrufkonventionen zwischen systemeigenen und reinen Kompilierungen.

Ahja.... Kapier leider den Satz nicht!
Das Beispiel dazu passt schon eher, weil ich eine Funktion in einem NAmespace habe, die ich ähnlich exportieren will:

// LNK2028.cpp
// compile with: /LD
__declspec(dllexport) int func() {
   return 3;
}

Dabei steht noch, dass diese funktion implizit __cdecl ist. Was heisst das jetzt für mich? Muss ich meine Funktion in eine Klasse reinpacken? Muss ich die anders exportieren?? Wenn ja, wie? In der MSDN steht leider nicht dabei, wie man diesen Fehler behebt!

Wär super, wenn mir nochmal jemand auf die Sprünge helfen könnte! Danke schon mal!

[NewtonsLaw]

So, morgen zusammen!

Hab mir die Fehlermeldungen heut nacht nochmal angeschaut und hab bemerkt, dass die Fehler immer bei ner Klasse auftreten, von der ich eine Instanz anlegen will in meinem Programm. Die Klasse ist noch unmanaged, im guten alten C++ geschrieben! Aber das sollte ja kein Problem darstellen, oder?
Hier mal bissl Pseudo-Quellcode:

namespace myNamespace{

	class __declspec(dllexport) myClassName
	{
		public:
			//Standardkonstruktor
			myClassName(void);
			// Standard-Destruktor
			~myClassName(void);
                         ......
          }
}

In der schlauen MSDN steht drin, dass man somit alle public-Memberfunktionen der Klasse exportieren kann. Die erste Fehlermeldung meckert aber wegen meinem Konstruktor rum (sofern ich das aus der kryptischen Fehlermeldung richtig deute), nach ca. 10 Fehlern wegen Konstruktor/Destruktor kommen dann die Memberfunktionen dran (die alle public sind und wie oben exportiert werden).....
Muss ich also die Memberfunktionen doch noch anders exportieren? Oder anders aufrufen (Aufruf für die Instanz im Programm eben über myNamespace::myClassName)?
Bin langsam am Verzweifeln... Glaub ich nehm nen Strick und erschiess mich!
Danke schon mal im Voraus!! Hoffe jemand hat nen Tipp für mich!

[Knuddlbaer]

Danke schon mal im Voraus!! Hoffe jemand hat nen Tipp für mich!

Klar, immer wieder gerne. Poste Fehlermeldungen

[NewtonsLaw]

Fehlermeldungen:

173 mal die gleiche:

Error 27 error LNK2028: unresolved token (0A000056) "public: void __thiscall NamespaceDLL::KlassennamenBasisklasse::MemberfunktionWertSetzen(double)" (?MemberfunktionWertSetzen@KlassennamenBasisklasse@NamespaceDLL@@$$FQAEXN@Z) referenced in function "private: void __clrcall NamespaceAnwendung::Form1::RegKartenEinlesen(class NamespaceDLL::KlassennameAbgeleitetKlasse* const)" (?RegKartenEinlesen@Form1@NamespaceAnwendung@@$$FA$AAMXQAVKlassennameAbgeleitetKlasse@NamespaceDLL@@@Z) Form1.obj

Der Fehler kommt 173mal, mit so ziemlich allen Memberfunktionen meiner Klasse. Diese sind alle public und exportiert wie oben beschreben...

Hab die DLL aus meinem Projekt wieder rausgenommen und nehme direkt die h und cpp-Files, da klappt es. Liegt also wohl an einer falschen Exportierung meiner Klasse/Memberfunktionen??

[Knuddlbaer]

Hast Du die lib hinzugefügt ?

[NewtonsLaw]

Knuddlbaer schrieb:

Hast Du die lib hinzugefügt ?

Hinzugefügt per Verweis oder in das Arbeitsverzeichnis kopiert??

Derzeit liegt die noch im debug-Ordner, zuusammen mit der *.dll. HAbs nicht geschafft nen Verweis auf die zu erstellen, #using und #include geht auch nicht.
Mein DLL-Projekt dagegen ist per Verweis hinzugefügt (so wie in der MSDN). Ist so die LIB dann doch nicht bekannt?

Hier nochmal der Link: http://msdn2.microsoft.com/de-de/library/ms235636(VS.80).aspx
Einzigen Schritt den ich nicht hinbekommen habe: Schritt 5 bei "So verwenden Sie Funktionen der Klassenbibliothek in der Konsolenanwendung" (die Sache mit dem PATH, allerdings hat das bei nem andren Projekt auch ohne geklappt)

[Knuddlbaer]

Datei hinzufügen -> lib auswählen fertig

[NewtonsLaw]

Knuddlbaer schrieb:

Datei hinzufügen -> lib auswählen fertig

Ist mir jetzt fast schon peinlich, aber ich frag trotzdem:
Wo mach ich das? Unter "Verweise"? Oder im Menü Datei???

[NewtonsLaw]

OK, habs gefunden... Bin wohl manchmal zu ungeduldig!

Normalerweise wird doch die lib automatisch mit erstellt, oder? Weil bei mir macht er die lib nur, wenn ich das in den Projekteinstellungen explizit angebe..... Nervt bissl, das Ding immer zweimal zu kompilieren, wenn Änderungen vorgenommen wurden!

Trotzdem allen ein Dankeschön!