ich habe mal wieder ein Problem:

Musste über die Ferien einige Projekte mit VC++ machen. Ich habe diese kompiliert und den Debugordner zum Testen auf andere PC's kopiert, bei denen aber kein VC++ installiert ist.

Und prompt meckerten die PC's gleich rum: Fehlende DLL.
Is mir auch einleuchtende, schließlich gabs ja schon damals für VBasic Runtime-Komponenten die solche DLL's beinhalteten.

Gibts so ein Paket auch für VC++ oder muss ich erst umständlich mit dem Installshield Assi eine Setup Datei basteln?

CU

Deswegen stellt der Project-Assistent beim erstellen eines neuen Projectes die Frage, ob du die MFC statisch oder dydnamisch gelinkt haben willst.

Bei dynamisch, musst die dll mitgeben, sonst laeufts ned ... ich glaub bei XP ist aber eine dabei oder ???

Ciao ...

Bei dynamisch, musst die dll mitgeben, sonst laeufts ned ... ich glaub bei XP ist aber eine dabei oder ???

Bei Windows sind immer nur die Release-Versionen der Laufzeitbibliotheken dabei. Bei einem Debug-Build muss man also immer die DLLs mitgeben.

Und bitte, bitte nicht die Debug-MFC statisch linken...

Und bitte, bitte nicht die Debug-MFC statisch linken...

Was spricht denn dagegen die Debug-Version statisch zu linken ?

Was spricht denn dagegen die Debug-Version statisch zu linken ?

Die Größe und die Sinnlosigkeit.

Warum soll ich eine große Bibliothek einschließlich der sehr umfangreichen Debuginformationen fest an mein Programm hängen, wenn dieselbe Bibliothek als Releaseversion in Form einer DLL praktisch überall verfügbar ist?

wie kann ich das Problem jetzt lösen, ohne alles in ein neues Projekt zu schreiben.

CU

wie kann ich das Problem jetzt lösen, ohne alles in ein neues Projekt zu schreiben.

Evtl. kannst du ja den Visual Studio Installer benutzen:
http://msdn.microsoft.com/vstudio/downloads/tools/vsi11/default.aspx

Ich habe ihn noch nie getestet. Ich verwende NSIS:
http://nsis.sourceforge.net/site/index.php

wie kann ich das Problem jetzt lösen, ohne alles in ein neues Projekt zu schreiben.

Erstell einen Release-Build.

nachdem ich eine Nacht drüber geschlafen habe ist mir noch eine Idee gekommen.
Ich probiere ich die 2 Links mal aus und dann werde ich versuchen, die fehlenden DLL Dateien einfach ins System-Verzeichnis zu kopieren. Wenn das klappen sollte dann bastel ich mir eine BATCH-Datei und lege die DLL's dabei.

Danke für eure Hilfe

CU

Ich probiere ich die 2 Links mal aus und dann werde ich versuchen, die fehlenden DLL Dateien einfach ins System-Verzeichnis zu kopieren.

Versuch doch erst mal, einen Release-Build zu erstellen. Mit hoher Wahrscheinlichkeit gibt's dann gar keine fehlenden DLLs.

Manchmal hat man das Gefühl, vor eine Wand zu reden...

Ein Tip Erstellen > Aktive Konfiguration dann Release auswählen.
Und blos nicht in den Projekt Einstelungen was verändern.

Die MFC in der Release Version liegt auf fast jedem Windows ab Win 98.

@MFK: da kannste von ausgehen, diese Frage wird doch alle 3 Tage hier gestellt. Siehe http://www.c-plusplus.net/forum/viewtopic.php?t=51763

fiffi schrieb:

Was spricht denn dagegen die Debug-Version statisch zu linken ?

Die Größe und die Sinnlosigkeit.

Warum soll ich eine große Bibliothek einschließlich der sehr umfangreichen Debuginformationen fest an mein Programm hängen, wenn dieselbe Bibliothek als Releaseversion in Form einer DLL praktisch überall verfügbar ist?

aber wenn andere programme die gleichen dlls nutzen bzw neuere mitbringen ist der effekt hinüber, oder?

Ich würde jetzt mal gerne einen vernüftigen Grund hören, warum man überhaupt eine Debugversion statisch linken will bzw. warum man daraus keine Release machen soll???? Irgendwie verstehe ich das hier nicht. Es ist doch überaus praktisch (bei VC++ 6.0) ein Release zu machen, weil die DLL´s sowieso, schon wie gesagt, ab W98 vorhanden sind???
Wenn man VC++ 7 verwendet muss man sowieso ein Release statisch linken. Weil man dieses Prog sonst nirgends nutzen kann ausser auf Maschinen auf denen schon die neuen Bibliotheken vorhanden ist.

Also irgendwie will mir das nicht so ganz in die Birne warum herumgetüftelt wird, wie man DLL´s ins Windows kopiert nur damit die Debug Version läuft.

Wenn mir das mal jemand freundlicherweise Erklären könnte?

Hellsgore

aber wenn andere programme die gleichen dlls nutzen bzw neuere mitbringen ist der effekt hinüber, oder?

Ich weiß nicht genau, welchen "Effekt" du meinst, aber wenn andere Programme die gleiche DLL nutzen, dann ist das gut so, denn dafür sind DLLs da.

Unterschiedliche MFC-DLL-Versionen sind ein Problem, allerdings eins, das recht selten ist. Und ich möchte wetten, dass in der Vielzahl der Fälle, bei denen hier das statische Linken als "Lösung" empfohlen wird, keine Versionsprobleme auftreten würden.

Und wenn dann doch einmal ein Versionsproblem vorliegt, dann muss man halt ein Update anbieten. Es ist ja nicht so, dass Microsoft die MFC-Updates im Monatstakt rausgibt.

Wenn es denn gar nicht anders geht, kann man immer noch die Release-MFC statisch linken. Aber es gibt überhaupt keinen Grund, die Debug-MFC statisch zu linken.

Ich denke es schwirren im Internet, wie auch hier, immer mal wieder Holzhammer Methoden rum um dieses "Problem" zu lösen.

Ist die MFC eigentlich schneller wenn sie statisch gelinkt wird ? Ich mein natürlich nur die Release Version.

Ich muss das Programm auf einer Workstation im Hörsaal starten (wegen Beamer und Verteidigung...), auf der aber kein VC++ installiert ist. Also muss ich die Debug-Version nehmen. Und dann kommen die Fehlermeldungen.

Mehr nicht.

CU

Ich muss das Programm auf einer Workstation im Hörsaal starten (wegen Beamer und Verteidigung...), auf der aber kein VC++ installiert ist. Also muss ich die Debug-Version nehmen.

Wie kommst du denn darauf? Die Schlussfolgerung musst du mir erklären.

Die Debugversion "musst" du nur nehmen, wenn du das Programm debuggen willst. Willst du das auf dieser Workstation?

Mit der startet man das kompilierte Programm. Das klappt ganz gut, wenn VC++ auf dem Computer installiert ist, auf dem ich das Projekt starte.

Wenn kein VC++ installiert, kann man die EXE nicht starten, dann kommen die Fehler mit den fehlenden DLL-Dateien.

So habe ich das bis jetzt immer gemacht. War vermutlich falsch.

Gibts irgendwo ne Anleitung, wie man eine normale ausführbare Datei aus seinem Projekt erstellt?

CU

Gibts irgendwo ne Anleitung, wie man eine normale ausführbare Datei aus seinem Projekt erstellt?

HeikoKortlang hat in diesem Thread bereits beschrieben, wie man einen Release-Build erstellt...

Danke allen.

CU

Unterschiedliche MFC-DLL-Versionen sind ein Problem

Noe ! Jedes Programm was den Anspruch erhebt, ernst genommen zu werden, bringt nen Setup mit, sobald nur irgendetwas dynamisch gelinkt wird. Da alle Dlls abwaertskompatibel sein (sollten), ist das kein thema ... installieren, und bei bedarf wird die neue dll druebergepumpt.

Zum weiterreceischen an freunde auf den 2. Rechner etc ist das natuerlich overhaed. Aber wenn man mit nem VC++ 7 compiler ne exe erstellt, sollt man wissen, das man die mfc.dll dann auch an den rechner mit vc++ 6.0 oder ganz ohne VS geben sollte ...

Und blos nicht in den Projekt Einstelungen was verändern.

5 minuten nach dem erstellen eines Projektes mit dem VC++ 6.0 ist nix mehr so wie vorher !!!
die Temp-verzeichnisse liegen doof.
Warum sieht man nem binary ned an, wie es compiliert wurde !
*.dbg.exe, *.exe *.U.dbg.exe *.U.exe helfen echt enorm ...
das selbe mit dll lib etc ...
warum kommen die nicht gleich in nen /bin verzeichniss ???

Ciao ...

Was kann ich denn nun machen, bzw. was ist besser:

DLL's manuell ins System-verzeichnis kopieren oder eine Release-Version erstellen.

Bitte auf normal deutsch und für solche, die erst seit 2 Jahren C++ Programmieren.

CU

Unterschiedliche MFC-DLL-Versionen sind ein Problem

Noe ! Jedes Programm was den Anspruch erhebt, ernst genommen zu werden, bringt nen Setup mit, sobald nur irgendetwas dynamisch gelinkt wird.

Das ist IMHO genau die Argumentation, die so viele Anfänger zu "statisch-Linkern" macht. Ich will kein Setup erstellen oder weiß nicht wie -> statisch linken. Die Programme vieler, die hier fragen, erheben diesen Anspruch einfach nicht...

Da alle Dlls abwaertskompatibel sein (sollten), ist das kein thema ...

Ich will dir ja nicht deine Illusionen rauben, aber...

Warum sieht man nem binary ned an, wie es compiliert wurde !
*.dbg.exe, *.exe *.U.dbg.exe *.U.exe helfen echt enorm ...
das selbe mit dll lib etc ...
warum kommen die nicht gleich in nen /bin verzeichniss ???

Fragen, deren Beantwortung niemandem weiterhilft....

Was kann ich denn nun machen, bzw. was ist besser:

DLL's manuell ins System-verzeichnis kopieren oder eine Release-Version erstellen.

Falls das immer noch nicht klar geworden ist: Letzteres.

Und blos nicht in den Projekt Einstelungen was verändern.

5 minuten nach dem erstellen eines Projektes mit dem VC++ 6.0 ist nix mehr so wie vorher !!!
die Temp-verzeichnisse liegen doof.
Warum sieht man nem binary ned an, wie es compiliert wurde !
*.dbg.exe, *.exe *.U.dbg.exe *.U.exe helfen echt enorm ...
das selbe mit dll lib etc ...
warum kommen die nicht gleich in nen /bin verzeichniss ???

Ciao ...

Ok hast mich erwischt, ich hab mich nicht klar ausgedrückt.
Aber über welches Thema reden wir hier?
Dies war darauf natürlich bezogen, ich habe ja den Weg beschrieben wie man ein Programm mit VC6 kompiliert das man weitergeben kann.

Ok hast mich erwischt, ich hab mich nicht klar ausgedrückt.

Nene, mein Fehler, klang so wie ... ruehr ja nix in den Projekteinstellungen an ! Das konnt ich so ned stehen lassen ... hat aber nix mit dem Thema zu tun !!!

Das ist IMHO genau die Argumentation, die so viele Anfänger zu "statisch-Linkern" macht. Ich will kein Setup erstellen oder weiß nicht wie -> statisch linken.

Ja, aber nicht die Argumentation ist schuld, sondern die Furcht vor der "Arbeit" ! Und halt die Furcht vor Dlls allgemein (Vertrieb gehoert dazu) ! Wer sich das ned antun will Soll statisch linken, zumindest im Release. !!! Und ja, ich linke auch oft und gern statisch ... wegens Geschwindigkeit (naja, ist auch Augenwischerei) und kompatiblitaet. User sind greasslich, und nen Setup Idiotendicht zu machen, ist manchmal auch ne Lebensaufgabe ! :p
Wenigstens Fragt hier M$ wenn es nen Project anlegen tut. Wenn man sich die Philosophie von M$ in sachen userinterface anschaut ... unterstreicht dieses Nachfragen nur die Beduetung der Tragweite dieser Einstellung ! :-)))

Die Programme vieler, die hier fragen, erheben diesen Anspruch einfach nicht...

Noe, trotzdem muss man sich mit der Sache auseinandersetzen. Frueher oder spaeter bekommt man die probleme. ist sicher hoffentlich auch nicht das letzte programm das einer schreibt ... :p
Das war auch mehr nen Hieb gegen die Programme, die man irgendwo auf zwielichtigen servern runterladen kann, um, sagenwir mal spielstaende zu manipulieren wo der Author voll stolz ist auf sein Werk (manchmal auch berechtigt) aber 123845 User die foren voll spammen, weil er vergessen hat die Dlls auszuliefern ... Nachtraeglich kommt zusaetzlich nen download, wo man die Dlls beziehen kann, und 237485673 Posts spaeter hat auch der letzte User begriffen, wie er das programm zum laufen bringt Verteilung gehoert mit zum Entwicklungsprozess !!! Und bei vielen Projekten hat die Verteilungsstrategie imensen Einfluss auf das Design !!!
Und freuh uebt sich ... wer spaeter mal nen leichtes leben haben will
@Marco230480

DLL's manuell ins System-verzeichnis kopieren oder eine Release-Version erstellen.

Beides !!!
Prinzipiell ... auf jedem rechner wo du nicht debuggst, nimmst ne release version !!! wenn das programm kopierst, auch sicherstellen das die (Release) dll auf dem rechner existiert. Musst kein setup schreiben sondern check einfach, ob die mfc*.dll aelter oder nicht vorhanden, dann kopier die rueber ... Das ist standard vorgehen auch bei den Profism, wenn sie kein Setup brauchen (also nur auf ne kleine anzahl von rechnern verteilen wo sie zugriff drauf haben).
Ich koennt jetzt erwaehnen das ichs auch so mache, tu ich aber nich ...
Ciao ...