✔ dll-Datei umbenannt, Funktion fehlerhaft

[jazde86]

Ich habe ein C++ Projekt bekommen, ändere den Namen der ausgegebenen dll-Datei nach Erstellung oder in den Projekteigenschaften, aber die Funktion im Programm ist dann fehlerhaft, heißt irgendeine Linker- oder Symbolangabe scheint er nicht zu finden.

Hat jemand einen Tip, wo ich suchen muß oder wie ich das korrigieren kann?

Ich habe zwei Testprojekte die Beispiele sind und in einem funktioniert das auch nach Umbenennen der dll noch einwandfrei, im anderen einfach nicht, finde jedoch keine Unterschiede in den Einstellungen.

 

[MCoder]

Hallo,

wie wird die DLL in die Testprojekte eingebunden? Wie vermute mal über ein Import-Library (*.lib), die dem Testprojekt hinzugefügt wird. In dieser Import-Library steckt der Name der DLL mit drinnen. Kontrolliere mal ob, nach deinen Umstellungen im DLL-Projekt auch die Import-Library entsprechend angepasst wurde bzw. du musst dann eigentlich auch die Testprojekte noch ändern, um die neue Import-Library einzusetzen.

Gruß
mbmun

 

[jazde86]

Hallo MCoder,

das Projekt besteht nur aus dieser einen DLL und die .lib wird korrekt neu erstellt, darin finde ich auch nur noch den neuen Namen.

 

[deepthroat]

Hi.

Wie lauten die Fehlermeldungen?

Bei mir wird das Projekt ohne Probleme erstellt.

 

[jazde86]

Richtig.

Es gibt auch keinerlei Fehlermeldung, wenn ich nun den Ausgabenamen umbenenne, nur die DLL funktioniert nicht mehr so, wie sie soll. Das heißt die Funktionalität geht verloren. Bei anderen Projekten kann ich die DLL auch im Nachhinein einfach umbenennen und sie läuft dennoch einwandfrei im Programm.

 

[deepthroat]

Dann erkläre doch bitte erstmal ganz genau was nicht geht und vor allem was genau du machst.

Bis jetzt wissen wir das irgendwie die Funktionalität (welche?) verloren geht, da irgendwelche (welche?) Symbole nicht gefunden werden können (warum? wie kommst du zu dieser Vermutung?)

Ganz hilfreich wäre auch ein Minimalprogramm welches das Problem demonstriert.

 

[jazde86]

Die DLL ist ein Plugin für den Instant Messenger Trillian, lädt eine Textdatei zur Versionsüberprüfung herunter, speichert diese lokal ab und öffnet eine MessageBox, wenn auf dem Server eine neuere Version, als in der lokal hinterlegten ini-Datei vorhanden ist.

Sobald die DLL umbenannt wurde, lädt der zwar noch die txt herunter, allerdings wird der Inhalt nicht wie üblich in die lokale Kopie geschrieben, die Datei ist dann einfach leer und somit öffnet sich auch die MessageBox nicht mehr.

 

[MCoder]

Hallo jazde86,

ist das bereitgestellte Projekt die ursprüngliche oder schon die umbenannte Variante?
Ich kann das Projekt aber leider nicht öffnen, weil ich kein VS2010 habe.

Die interessante Funktion ist hier wohl "downloadFile()". Um den Fehler auf die Spur zu kommen, solltest du versuchen, das DLL-Projekt zu debuggen. Das schaffst du, indem du als ausführbares Programm den Trillian angibst (Projekteinstellungen -> Debugging -> Befehl). Falls du mit dem Debugging nicht zurechtkommst, kannst du alternativ auch Messageboxen im Code einfügen und dir so bestimmte Daten anzeigen lassen.

Gruß
MCoder

 

[deepthroat]

Was auffällig ist:

Die downloadFile Funktion gibt immer true zurück (wenn home_directory gesetzt ist). Das ist unsinnig, da der Download natürlich jederzeit schief gehen kann.

Fehlerbehandlung fehlt völlig.

1. InternetOpen kann NULL zurückgeben.
2. InternetOpenUrl kann NULL zurückgeben.
3. InternetCloseHandle kann FALSE zurückgeben.
4. es wird nicht geprüft ob die Datei überhaupt geöffnet werden konnte.
5. es wird nicht geprüft ob etwas in die Datei geschrieben werden konnte.

 

[jazde86]

Fehlerhafter Dateipfad durch path.resize

Ich danke euch ganz herzlich! Durch diese klasse Hinweise habe ich herausgefunden, daß der den Dateipfad nach Anzahl an Stellen abschneidet mit

path.resize(path.length() - 16);

und sobald die Datei nicht eine Länge von 16 Stellen hat der Pfad logischerweise nicht mehr stimmt.

Die überall fehlende Fehlerbehandlung ist für mich auch Ansporn genug mich nun mehr in das Thema einzuarbeiten. ;-) Sagen wir es ganz ehrlich: schlampig programmiert.

@MCoder: Der Ausgabedateiname ist der ursprüngliche.