[Solved] Mein Programm braucht auf anderen REchern zusätzliche dll's die es auf meinem nicht braucht.
-
Ich habe ein kleines Programm geschrieben, (Visual Studio 2008 Express) .
Dieses benutzt curl sowie gtkmm. Funktioniert auf meinem Rechner auf wunderbar.
Auf anderen Rechner hatte ich zuerst eine Fehlermeldung von wegen fehlerhafter Anwendungskonfiguration, dieses ließ sich jedoch durch ändern der Laufzeitbibliothek gelöst (war ausversehen auf dll, funktionierte wie gesagt trotzdem bei mir)Nun jedoch wirft es auf anderen Rechnern jedoch eine Fehlermeldung, die besagt, das libsasl.dll fehlt. Auf meinem Rechner existiert diese jedoch nur im Verzeichnis von Tortoisesvn/bin
Hat irgendwer eine Ahnung warum dieses so ist?
-
Hast du die irgendwo bei dir mitgelinkt?
-
Hm nicht wissentlich, kann aber sein Gtkmm oder Curl die benutzen.
--paar Minuten vergangen--
Hm.., aber in meiner PATH scheint der bin vom Tortoise drinne zu sein.
--paar Minuten mehr --
Jetzt habe ich mal alles dll's reinkopiert und die PATH zum test rausgenommen, jetzt geht es auf mienem Rechner, auf einem anderen sagt es jedoch:
Die Anwendung konte nicht richtig initialisiert werden (0xc0150002)
So gesehen bleibt damit die frage warum das Programm nicht auf anderen Rechnern geht.
-
Vielleicht eine alte Version irgend einer DLL? - Liefer mal deine mit, wie sie bei dir funktionieren.
-
Das ist ja das lustige daran, es ist exakt derselbe Ordner der bei mir läuft, zusammen mit den dll's die evtl. durch die PATH dinger hinzugekommen sind. (funktioniert bei meinem Rechner jetzt auch wenn man die PATH Einträge löscht)
-
Hmm. Dann vergleich mal die Computer. Probier es ebenfalls bei anderen aus.
OS sollte das wichtigste Kriterium sein und ev. kannst du ja mal probieren eine einfachere Anwendung zu verteilen. Sprich ein Hallo Welt Programm. Vielleicht liegt es auch an Einstellungen, die du bei deinem Compiler gemacht hast.
-
Könnte sein, dass es an den CRT-DLLs liegt.
Falls dein Programm eine der DLLs "msvc?80.dll" bzw. in der Debug-Version "msvc?80d.dll" benötigt (die Zahl könnte u. U. eine andere sein), dann zeigt Windows beim Starten des Programms genau diese Fehlermeldung, wenn diese DLLs nicht installiert sind.
Auf deinem Rechner sind sie installiert, da VS dies bei seiner Installation gleich mit erledigt. Auf anderen Rechnern gibt es diese DLLs halt nicht.
Du kannst folgendermaßen ausprobieren, ob es daran liegt:
Kopiere den kompletten(!) Inhalt des Ordners <VS-Dir>\VC\redist\x86\Microsoft.VC80.CRT in den Ordner deines Programms. Das müssten vier DLLs und eine Manifest-Datei sein. <VS-Dir> ist natürlich das Installationsverzeichnis von Visual Studiu.
Die Dateien müssen unbedingt in demselben Ordner wie deine EXE liegen; PATH hilft hier nicht.
Wenn dein Programm nun auf dem fremden Rechner läuft, lag's an den CRT-DLLs.
Stefan.
EDIT: Für die Debug-Version brauchst du den Inhalt von <VS-Dir>\VC\redist\Debug_NonRedist\x86\Microsoft.VC80.DebugCRT. Das Verteilen dieser Dateien ist allerdings illegal.
-
du könntest auch einfach einmal versuchen dein programm mit einem anderen kompiler (z.B. dev c++) zu kompilern. das löst solche probleme häufig, gerade bei mircrosoft visual c++ 2008 treten mehr fehler auf anderen rehnern auf (zB falsche side-by-side.konfiguration usw.) was beispielsweise bei dev c++ nicht der fall ist.
vielleicht löst das dein problem ja schon, wäre eine der einfachsten lösungen
mfg,
andi01.
-
@andi01,
Wie bitte? Wenn man alles korrekt macht und auch weiss was man tut, dann geht die Auslieferung mit VS ohne Probleme. Problem ist meistens nur, dass die Anfänger keine Ahnung haben und dann ihr scheitern VS zuschieben.Übrigens zu DevC++:
http://www.c-plusplus.net/forum/viewtopic-var-t-is-237002.html@Empire Phoenix,
Probier zuerst einmal die CRT statisch zu linken. Per default ist die immer dynamisch gelinkt. Unter:
Project Properties -> Configuration Properties -> C/C++ -> Code Generation -> Runtime Library
Dort auf MT, bzw. MTd setzen.Falls du das nicht machen willst, musst du beim Computer, welcher kein VS hat, das Microsoft Visual C++ 2008 Redistributable installieren. Kannst du von Microsoft runterladen, bzw. sollte auch irgendwo im Installationsverzeichnis von deinem Visual Studio vorhanden sein.
Wenn du dies richtig gemacht hast und es immer noch zu Fehlern kommt, dann kann man mal weiterschauen. Dann wird wahrscheinlich eine weitere Bibliothek dazugelinkt. Vielleicht sogar durch irgendwelche
pragmaAnweisungen in curl oder gtkmm, wäre aber eine ziemlich schlechte Sache von den Bibliotheken, wenn dies einfach automatisch passiert.Grüssli
-
Ich hatte am anfange mingw + msys + eclipse benutzt, aber dort hatte ich generelle Probleme alles zum laufen zu bringen, deshalb hatte ich mich unter fluchen dann dazu durch gerungen den ms Krams zu benutzen.
Warum sind die debug Dinger eigentlich illegal
?Welche einfach/intuitiv zu benutzenden IDE's könnt ihr denn sonst noch empfehlen?
-
Empire Phoenix schrieb:
Nun jedoch wirft es auf anderen Rechnern jedoch eine Fehlermeldung, die besagt, das libsasl.dll fehlt. Auf meinem Rechner existiert diese jedoch nur im Verzeichnis von Tortoisesvn/bin
Dann wird auf deinem Rechner wohl PATH auf Tortoisesvn/bin verweisen.
DAS Tool schlechthin wenn es um DLL Abhängigkeiten geht: http://www.dependencywalker.com
-
Empire Phoenix schrieb:
Warum sind die debug Dinger eigentlich illegal
?Weil's Microsoft so will. Aber so schlimm ist das ja nicht - du wirst ja nicht die Debug-Versionen deiner Software verteilen.
Empire Phoenix schrieb:
Welche einfach/intuitiv zu benutzenden IDE's könnt ihr denn sonst noch empfehlen?
Unter Windows ist für mich Visual Studio das Maß aller Dinge. Insbesondere der Debugger schlägt alles andere um Längen. Möchte ich keinesfalls missen.
Ich entwickle gern meine (privaten) Projekte parallel mit VS und MinGW. Es ist ohnehin empfehlenswert, zwei verschiedene Compiler auf den Code loszulassen. Debuggen nur mit VS (gdb ist eine Qual), ansonsten reicht mir die Kommandozeile. Wenn ich etwas weitergeben möchte, ist das immer die MinGW-Version.
Stefan.
-
Habe endlich den Fehler gefunden.
Offensichtlich habe ich eine debug dll von gtkmm benutzt, und das mögen alle anderen Rechner nicht (warum auch immer).
Danke an alle die geantwortet haben und vielen Danke für den Dependency Walker, der wird bestimmt noch nützlich sein.
-
DStefan schrieb:
Aber so schlimm ist das ja nicht - du wirst ja nicht die Debug-Versionen deiner Software verteilen.
Das wäre manchmal durchaus praktisch!
Auch für Embedded-Sachen (Windows XP embedded) wäre es praktisch, wenn man die Debug Runtime DLLs mit ausliefern dürfte. Würde sehr beim Testen helfen.
-
hustbaer schrieb:
DStefan schrieb:
Aber so schlimm ist das ja nicht - du wirst ja nicht die Debug-Versionen deiner Software verteilen.
Das wäre manchmal durchaus praktisch!
Auch für Embedded-Sachen (Windows XP embedded) wäre es praktisch, wenn man die Debug Runtime DLLs mit ausliefern dürfte. Würde sehr beim Testen helfen.Das ist interessant. In wiefern würde es beim Testen helfen? Zum Debuggen müsste man doch den ganzen VS-Krempel installieren. Oder meinst du die Heap- und Range-Checks der Debug-Version?
Stefan.
-
Ich meine einerseits Debug Heap, ASSERT/VERIFY/TRACE, evtl. erweiterte Log Ausgaben etc.
Allgemein halt die Möglichkeit Debug Builds laufen zu lassen.Und ein Remote-Debugger ist auch schnell draufkopiert, so dass man auch debuggen könnte.
Natürlich könnte man auch eine Projekt-Konfiguration machen wo ASSERT/VERIFY/TRACE etc. "an" sind, die aber trotzdem mit den Release-Runtimes linkt. Ist aber umständlich, und SO oft bräuchte man es nicht.
Kommt vielleicht einmal alle 2 Monate oder so vor, dass ich mir denke "da spiel ich jetzt einfach die Debug-Version drauf, und dann guck ich mir das an" - bis mir dann wieder einfällt, dass auf unserem XPe Image garkeine Debug DLLs drauf sind.Die dann jedesmal wieder draufkopieren ist halt etwas nervig.
