4. [Gelöst] DLL-Probleme

[Gelöst] DLL-Probleme

  • N

    Hab im Netz folgendes gefunden:
    http://www.functionx.com/visualc/libraries/staticdll.htm
    Irgendwie wird da ne DLL ganz anders erstellt als in der MSDN?!?! 😕 👎 Was issn jetzt richtig??? Auf MSDN steht nix von extern "C" usw........
    http://msdn2.microsoft.com/de-de/library/ms235636(VS.80).aspx
    Dachte so ne DLL kann man sich ganz einfach selbst erstellen, wusste net dass das so ein Gewirre ist! Aber kann doch net so schwer sein, oder!??!?!

    0
  • N

    Weiß denn da niemand Bescheid???????? 😞 😕

    BitteBitteBitte! 😉

    Wie gesagt, will mir nur selbst ne DLL erstellen aus h und cpp Dateien, die ich schon da hab...... Wie ich das angegangen bin steht ja oben, nur funktioniert das eben (LEIDER) nicht.
    Im Netz werd ich auch nicht schlau, mal steht dieses "extern C" vor den DLL-Funktionen, mal nicht.... Steig grad echt nimmer durch, würd mich deswegen über Tipps oder Hilfe freuen!

    0
  • K

    Das extern "C" wird benötigt, damit der Funktionsname so bleibt wie er ist. Für C++ wird der Name einer Funktion/Methode mit Informationen erweitert.

    0
  • D

    Erstelle ein neues Projekt CLR => Klassenbibliothek

    Dort deine .h und .cpp reinnehmen die du als Klassenbiblio nutzten möchtest.
    Schau mal in der Doku unter <summary> nochmal nach, da steht ein Beispiel und wie du den Compiler einstellen musst (z. B. Compile mit /doc usw.)
    Deine erstellte dll dann in deine Projekte einbinden die diese Biblio nutzen sollen, du kannst nun die dll nutzen und Intellisense erkennt automatisch die xml(muss im gleichen Verzeichnis liegen wie die dll)
    Dann in den Projekteigenschaften noch eine Verweis auf die dll und schon siehst du deine Klassenbibliothek im Objektbrowser.

    Bis später

    0
  • N

    So, hab das mal genau so gemacht wie Destructor vorgeschlagen hat....
    Hat aber nix gebracht!! Das erstellen der DLL funktioniert ohne Probleme, aber ich kann die Funktionen nicht nutzen, die in meiner DLL drinstecken...Namespace und Funktionsname sind unbekannt. Ebenso funktioniert es mit dem Objektbrowser nicht, wobei mir das an sich wurscht ist, solang ich die Funktionen eben verwenden kann.
    Hier mal etwas Quellcode:

    // DLL_Test.h

#pragma once

#include <math.h>

using namespace System;

namespace MathFunktionen {

	// Definition der Kreiszahl PI für spätere Berechnungen
	 __declspec(dllexport) const double PI = 4*atan(1.0);

	 ///<summary>
	// gibt den DOUBLE Wert des berechneQuadrats von dWert zurück: dWert^2
	///</summary>
	 __declspec(dllexport) double berechneQuadrat(double dWert);
.........
}

    // Dies ist die Haupt-DLL.

#include "stdafx.h"

#include "DLL_Test.h"

///<summary>
// gibt den DOUBLE-Wert des berechneQuadrats von dWert zurück: dWert^2
///</summary>
double MathFunktionen::berechneQuadrat(double dWert){
	return(dWert * dWert);
.......
}

    Kompiliert ist das alles mit den Optionen \clr und \doc; das funktioniert auch ohne Probleme!
    Eingebungen wird die DLL dann über #using "Test_DLL.dll", weil sie im gleichen Verzichnis liegt. Verweis hab ich ebenfalls auf die DLL im Projekt hinzugefügt, passt eigentlich alles!

    Nur wo ist der Fehler?? Werd nicht schlau draus, warum mein Namespace und meine Funktionen nicht bekannt sind?????

    0
  • K

    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 ?

    0
  • N

    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?????

    0
  • K

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

    0
  • ?

    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.

    0
  • ?

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

    0
  • N

    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!

    0
  • ?

    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.

    0
  • J

    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

    0
  • N

    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!

    0
  • N

    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! 👍

    0
  • K

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

    Klar, immer wieder gerne. Poste Fehlermeldungen

    0
  • N

    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??

    0
  • K

    Hast Du die lib hinzugefügt ?

    0
  • N

    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)

    0
  • K

    Datei hinzufügen -> lib auswählen fertig

    0
Anmelden zum Antworten