qtforum.de

Ich habe ein Programm, das eine DLL verwendet.
Ich binde die Lib zur DLL mit: LIBS +="./DLL/TestDLL.lib" ein.
Wenn ich die DLL in das DEBUG oder das Source verzeichnis kopiere läuft, das Programm.
Wenn ich dieses aber nicht mache, bekomme ich die Fehlermeldung beim Start des Programmes:
Die Anwendung konnte nicht gestartet werden, weil TestDLL.dll nicht gefunden wurde. Neuinstallation der Anwendung könnte das Problem beheben.

Es wird die Fehlermeldung vom Debuger ausgegeben:
Eine nicht behandelte und nicht mehr ausführbare STATUS_DLL_NOT_FOUND-Ausnahme wurde während des Ladeprozesses ausgelöst

Auch ein Breakpoint in der main-Methode hilft nicht.

Kann einer von euch mit dieser Problembeschreibung etwas anfangen?
Ich benutze das Visual Studio .NET, liegt es vielleicht an irgendwelchen Compilereinstellungen?

Ich hoffe, ihr könnt mir helfen,

Grisu

Das Programm muss die DLL schon finden können. Was hast Du denn jetzt erwartet? Das das Programm die ganze Platte danach durch sucht?

Grisu80 hat geschrieben:Ich habe ein Programm, das eine DLL verwendet.
Ich binde die Lib zur DLL mit: LIBS +="./DLL/TestDLL.lib" ein.
Wenn ich die DLL in das DEBUG oder das Source verzeichnis kopiere läuft, das Programm.
Wenn ich dieses aber nicht mache, bekomme ich die Fehlermeldung beim Start des Programmes:
Die Anwendung konnte nicht gestartet werden, weil TestDLL.dll nicht gefunden wurde. Neuinstallation der Anwendung könnte das Problem beheben.

Was hast du denn erwartet? Die DLL muß im gleichen Ordner liegen wie deine .exe. Oder in einem Ordner, der über die Systemvariable PATH erreichbar ist. Typisch ist das c:\windows\system32

G.

gerome69 hat geschrieben:Typisch ist das c:\windows\system32

Programm-DLLs gehören ins Programmverzeichnis. System32 sollte dem System vorbehalten sein, sonst handelt man sich nur Probleme ein.

macman hat geschrieben:Programm-DLLs gehören ins Programmverzeichnis. System32 sollte dem System vorbehalten sein, sonst handelt man sich nur Probleme ein.

Das sehe ich prinzipiell genauso wie du, wenn es spezielle DLLs sind, die ich selbst entwickelt habe.
Wenn es aber sowas wie "mysql.dll" ist, dann frage ich in meinem Installer ab:
1. Darf der Benutzer überhaupt nach System32 schreiben?
2. Gibt es dort schon noch keine mysql.dll?

Wenn beide Fragen mit ja beantwortet wurde, kopiert mein Installer sie dort hin, ansonsten ins Programm-Verzeichnis.

G.

Selbst bei 3thd level Dll's sollt man sich ueberlegen wo man sie hinpappt.

ok,die mysqldll ist ne ziemlich saubere C Dll, und auch ganz gut abaertskompatibel. Aber wenn ich z.b. nen programm ausliefere, welche die mysqldll version 3 mitbringt und sie ins system 32 installiere ....

Dann kommst du und schaust .... mysql.dll vorhanden, alles in Butter aber du brauchst z.b. die version 4 (erweiterte funktionalitaet) .... ich hoffe du checkst dann die version ^^

wenn aber beide programme die dlls in eigenen verzeichnissen haben, gibts den konflikt nicht.

Viel lustiger wird es, wenn die Dll klassen exportiert (die werden gern ueber die importlibs angezogen) ... dann zaehlt nicht nur die version, sondern auch der compiler (binaerkompatiblitaet).

Hatten schon die lustigsten effekte, weil wir die QT-dlls ins system32 verzeichniss ausgeliefert haben. Boese falle wenn wer der nen anderen compiler nutzt (mingw / intel / microsoft) auf die selbe idee kommt.

Deshalb liefern wir die benoetigten dlls nur noch in einem appliaktionsverzeichniss aus, dann kann man sicher sein dass die DLL's passen

Ciao ....

RHBaum hat geschrieben: Dann kommst du und schaust .... mysql.dll vorhanden, alles in Butter aber du brauchst z.b. die version 4 (erweiterte funktionalitaet) .... ich hoffe du checkst dann die version ^^

Du hast meinen Text nicht richtig gelesen.
Wenn es in system32 schon eine dll gleichen Namens gibt, dann installiere ich immer meine dll ins Applikationsverzeichnis, um genau solchen Versions- und Kompiler-Problemen zu entgehen!

G.

Ja dann ist das problem aber genau andersrum .... stell dir vor die lieferst die version 4 aus, und ich brauch die version 5

Mein Programm installiert, super laeuft ....
Dein Programm installiert, das laeuft dann auch, nur meins geht nimmer .... (du hasst von version 5 auf 4 downgraded).

Im Falle unserer Firma wuerdest du mit dem verhalten gar keine Freigabe fuer dein Programm bekommen. D.H. das dein Programm in unserer Firma nicht offiziell eingesetzt werden wuerde.

Wie gesagt, bei sowas solltest du mindestens die version checken .....
und hoffen das der hersteller bei major releases (keinerlei kompatiblitaet) den dateinamen aendert (mysql2.dll) z.b.

Ciao ...

Hallo alle zusammen,
vielen Dank für die vielen Hinweise.
Eine DLL ist nun mal kein Plugin . Ich dachte ich könnte den Pfafd zu den DLLs mit addLibraryPath setzten. Aber das scheint wohl nicht so zu sein.

Ich hätte noch eine andere Frage, vielleicht sollte ich da ein neues Topic für aufmachen?
Wann nimmt man eigentlich ein Plugin und wann eine DLL?
Ich finde die Plugins von der Anwendung her viel zu kompiliziert. Vor allem, wenn das Plugin 15-30 Klassen hat, oder benutzt man das Plugin prinzip nur für Widgets und ähnliches?

Grisu

RHBaum hat geschrieben:Ja dann ist das problem aber genau andersrum .... stell dir vor die lieferst die version 4 aus, und ich brauch die version 5

Mein Programm installiert, super laeuft ....
Dein Programm installiert, das laeuft dann auch, nur meins geht nimmer .... (du hasst von version 5 auf 4 downgraded).

Blödsinn!

Meine Installer schreiben nur dann nach system32, wenn es dort keine dll gleichen Namens gibt, sie überschreiben niemals!

Wenn dein Programm so installiert wurde, wie du schreibst, liegt in deinem Applikationsordner deine .exe und alle dafür benötigen dlls. Bei der Ausführung wird immer zuerst die dll im Applikationsordner gesucht und danach erst in PATH. Somit läuft deine Applikation völlig unabhängig von meiner.

Dann kommt mein Installer:
- Meine Applikation hat die zugehörige dll im gleichen Ordner wenn es schon eine dll gleichen Namens in system32 gibt => läuft
- Meine Applikation hat dann die zugehörige dll in system32, wenn es dort noch keine gibt gleichen Namens zum Zeitpunkt der Installation

Somit läuft beides!

Aber im Prinzip gebe ich dir ja recht: alle dll's im Zweifelsfalle immer in den Applikationsordner. Für die Qt-Libs ist das aber eine ganze Menge an MB, für eine mysql.dll mit ca. 100 KB müssen wir uns da echt nicht streiten.

G.

gerome69 hat geschrieben:Für die Qt-Libs ist das aber eine ganze Menge an MB

Aber gerade da ist es um so wichtiger, da man die Qt-DLLs in allen möglichen Varianten compilieren kann.

Meine Installer schreiben nur dann nach system32, wenn es dort keine dll gleichen Namens gibt, sie überschreiben niemals!

Ja aber andere programme koennten das ... und somit iss wieder dein programm, was mal funktioerte, in gefahr, wenn nen anderes deine benoetigte Dll updated.

Aber dann die frage, warum ueberhaupt ins system 32 schreiben zu wollen ? wenn es ja im Appl verzeichniss auch gehen muss und soll ....

Wann nimmt man eigentlich ein Plugin und wann eine DLL?

Naja der unterschied iss eigentlich fliessend.

Ne Dll is generell eine library, die deiner Exe funktionen zur verfuegung stellt. Besonderheit iss halt das das ding dynamisch geladen wird.

Das dynamisch ebnet hingegen wieder den weg zum Plugin.

Nen Plugin zeichnet sich dadurch aus, das es die funktionalitaet der exe bei vorhandensein erweitert.
Im Hintergrund werden dabei immer verzeichnisse nach plugins abgesucht, und die bei vorhandensein geladen.
Hauptmerkmal ist halt, das die exe ohne ein plugin trotzdem laeuft, nur halt weniger funktionen hat. Und das man die exe um funktionen erweitern kann, ohne die exe nochmal anfassen zu muessen.

Im einfachen "DLL" fall, wenn die richtige dll ned gefunden wird, bricht dein Program halt ab ....

damit ist der verwendungszweck auch schon geklaert ....
Kannst du damit leben, das wenn du neue funktionalitaet in form einer dll baust, du die exe auch anpassen, neu kompilieren und ausliefern musst, dann langt ne einfache dll

Willst du, das du oder jemand anders ne dll schreiben kann, die einfach in nen festgelegtes verzeichnis spult, und die alte exe dann total neue dinge tut (neue Hardware anbindung, neue fileformate .... etc) dannn wirst du richtige Plugins schreiben muessen

Ciao ...

Ciao ...

OK, dann habe ich das wohl verstanden.

Wenn ich jetzt einen Fehler in einer Methode einer Klasse habe, kann ich den aber beheben und nur die neue DLL ausliefern?

Grisu

Genau das ist ein Vorteil der Dll ....
Du kannst den Teil der funktionen der in der Dll steckt, seperat austauschen.
Nachteil: wenn sich die Schnittstelle (funktionen, methoden, Parameter return values) der Dll dabei anedern, gibts meist hickhack (man muss die exe dann doch anpassen und versionen checken).

Fuer einzelprojekte ned ganz so wichtig, aber wenn man Teilfunktionalitaet zu anderen Firmen / Programmierern auslagern will, hilft einen ne Dll gewaltig.

Ciao ...