Probleme mit DLL im Release-Build
-
Hi 2gether,
folgendes Problem: Habe eine EXE und eine DLL
1. EXE: Release Build, wird nicht geändert.
2. DLL: Debug Build, alles funktioniert wie es soll.Aber jetzt: Sobald ich die DLL als Release erstelle, geht nichts mehr, also kein Zugriff mehr.
Einstellungen werden keine verändert, ausser Häkchen bei Laufzeit-Packages weg.
Das merkwürdige ist, dass es bis Ende letzten Jahres noch funktionierte. Seitdem wurden 2 neue bool Parameter eingeführt.
Worüber ich gestolpert bin, ist erstmal folgendes( in der EXE ):
DLL wird über LoadLibrary geladen, in beiden Builds(DLL) ist das Handle != NULL.
Danach kommen weiter Initialisierungen.
Danach wird der DLL das Application->Handles der EXE übergeben. Und hier passiert nun folgendes:
- DLL mit Debug Build: Handle != 0
- DLL mit Release Build: Handle == 0
und das wars dann?!Wo kann/soll ich noch suchen? Woran kann das liegen? Doch an den Einstellungen? Wurden nicht verändert, und wegen 2 hizugefügten bool's???
Habe in der SuFu hier nichts passendes gefunden.
Wer schubst mich auf die richtige Fährte?
thx schonmal und grüssle
-
Smitty schrieb:
Einstellungen werden keine verändert, ausser Häkchen bei Laufzeit-Packages weg.
Das scheint mir doch die Ursache zu sein. Wenn Anwendung und DLL VCL-Klassen austauschen, mußt du bei beiden Laufzeit-Packages anschalten.
-
audacia schrieb:
Smitty schrieb:
Einstellungen werden keine verändert, ausser Häkchen bei Laufzeit-Packages weg.
Das scheint mir doch die Ursache zu sein. Wenn Anwendung und DLL VCL-Klassen austauschen, mußt du bei beiden Laufzeit-Packages anschalten.
Genau das ist ja das merkwürdige. Es läuft seit Jahren( habe das Projekt übernommen ) ohne Laufzeit-Packages( Release )!
Und wenn ich sie ausschalte, müssen ja die ganzen System-DLL's dazu. Und das soll nicht sein.Also weiter suchen.
Auf jeden Fall schonmal Danke audacia.
grüssle
-
Smitty schrieb:
Genau das ist ja das merkwürdige. Es läuft seit Jahren( habe das Projekt übernommen ) ohne Laufzeit-Packages( Release )!
Daß es zufällig funktioniert hat, heißt noch lange nicht, daß es richtig ist.
Smitty schrieb:
Und wenn ich sie ausschalte, müssen ja die ganzen System-DLL's dazu. Und das soll nicht sein.
Du meinst, wenn du sie einschaltest? Dann mußt du rtl*.bpl. vcl*.bpl und ein paar andere Packages mitliefern, ja. Was ist das Problem?
Smitty schrieb:
Also weiter suchen.
Brauchst du vermutlich nicht. Zeig mal deinen Code (und sag dazu, in welchem Modul er ausgeführt wird), dann kann ich mehr dazu sagen.
Funktioniert es denn wieder, wenn du Laufzeit-Packages aktivierst?
-
audacia schrieb:
Funktioniert es denn wieder, wenn du Laufzeit-Packages aktivierst?
Auf dem Entwicklungsrechner ja, so wie es soll.
Fehlt wohl doch ein Package?![Edit]-> habe mal alle .obj, .pch, tds, ... gelöscht, und plötzlich gehts wieder?!
grüssle
-
audacia schrieb:
... Wenn Anwendung und DLL VCL-Klassen austauschen, mußt du bei beiden Laufzeit-Packages anschalten.
du meinst bei die Schnittstellen Funktionen?
da gibt's nur char*, bool, int und WORD. Und einmal HANDLE. Das wars. Nix mit VCL-Klassen?!
Und das Problem:
- DLL mit Debug Build: Handle != 0
- DLL mit Release Build: Handle == 0
besteht immer noch.
Gibts im ReleaseBuild kein gültiges ApplicationHandle mehr?grüssle
-
Wenn du in der DLL auf globale VCL-Objekte wie
Application
zugreifst, brauchst du auch Laufzeit-Packages, sonst bekommt die DLL ihr eigenesApplication
-Objekt, und das hat natürlich kein Fensterhandle.Wenn das Handle nur an die DLL übergeben wird, sollte es aber auch ohne gehen. Kannst du mal den kritischen Code zeigen, also die Stelle, wo das Handle unerwarteterweise NULL ist (kannst du gut mit dem Debugger finden)?
-
Hallo audacia,
Code ist völlig OK. Habe eben eine 'alte' Version genommen und neu erstellt. Die damals mit genau diesem Code und diesen Einstellungen erstellte DLL funktioniert einwandfrei, die heute erstellte DLL bringt die genannten Fehler
Liegt wohl an einem CBuilder Update?
aktuell bei mir:
-> C++Builder 2010 Update 4
-> C++Builder 2010 Update 5 ( Database Pack )
-> C++Builder 2010 Boost UpdateWerde jetzt mal einen anderen Rechner mit dem Builder bestücken und dann die Updates manuell nachziehen. Mal schauen was passiert.
Aber vllt. liegt der Fehler ja im Win7(32)? Oder am Rechner( HW )? Oder ...?
Aber Danke für die Hilfe, erstmal
grüssle
-
Wenn du mir ein vollständiges Projekt bereitstellst, mit dem der Fehler reproduzierbar ist, schaue ich mir's an.
-
Sodele, Fehler gefunden. Nach Urlaub und etlichen Stunden des Fluchens ist nun der Fehler beseitigt.
Es lag an Indy10!!!
Also alles was FTP mit Indy10 war rausgeschmissen, durch API ersetzt, und schon lief wieder alles so wie es soll.
Aber nochmal ein big THANX an alle, die geholfen haben / helfen wollten
grüssle