spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Willkommen im Forum!

Zitat von »Papiertig0r«

ich muss jede neue und upgedatete Ressource (Grafik files, dlls etc) per Hand in den Release Ordner kopieren.

DLLs ja, aber wie oft macht man das schon?
Bei Ressourcen ist das nicht nötig. Du musst in den Projekteigenschaften unter "Debugging" nur das "Working directory" (keine Ahnung, wie das auf deutsch heißt) setzen. Setze es für alle Konfigurationen, d. h. für Debug und Release. Lass dich nicht von der Bezeichnung "Debugging" verwirren - die Einstellung gilt auch für Release. Relative Pfadangaben beziehen sich dann auf dieses Verzeichnis (solange du es nicht änderst). Am besten setzt du es auf das Projektverzeichnis (da, wo deine .vcxproj-Datei liegt) und legst dir dort ein "Data"-Verzeichnis für deine Ressourcen an. So brauchst du keine separaten Dateien für Debug und Release.

Du kannst die Dependencies auch automatisch beim Build in deinen Release / Output Ordner kopieren lassen.

Dazu gibt es in Visual Studio die "Buildereignisse" oder "Build events". Siehe dazu die Projekteigenschaften.
Damit kannst du dann typische Windows CMD-Befehle ausführen und dabei sogar noch Projekt-makros verwenden, wie copy "$(SolutionDir)TheBestGameEngine.dll" "$(TargetDir)"

Wenn du das dann in der entsprechenden Release-Konfiguration setzt, passiert das auch nur beim Release-Build

Zitat

Oh und meine zweite Frage ist: Wie kann ich dem Compiler mitteilen, dass ich die dlls gerne in einem Unterordner hätte (alle dlls mit der .exe in einem Ordner sieht immer so unaufgeräumt aus).

Wenn du das zur Laufzeit haben möchtest, musst du LoadLibrary aus der Windows API verwenden. Wie du Kompatibilität zu *nix oder anderen Plattformen herstellen möchtest, musst du entsprechend mit #if-Direktiven arbeiten.
Wenn du es während des Builds haben möchtest, kannst du in den Visual Studio Projekteinstellungen eine temporäre Path-Variable setzen.

Also die Dateien per Hand zu kopieren finde ich ziemlich unschön. Ich will auch nicht meinen Ausgabeordner im SVN einchecken, und ich will den Ausgabeordner einfach vom Backups ausschließen können, ohne das ich nur die Hälfte gesichert habe.
Die Sache mit dem ändern Arbeitspfades finde ich auch nicht schön, weil ich dann nicht einfach den Ausgabeordner als Ausgabe ansehen kann weil man wieder noch Hand anlegen müsste und außerdem herrschen dann andere Bedingungen beim Testen. Da würde meine Anwendung andauernd von sich aus im Quellcode-Ordner verpfuschen. Da finde ich schon besser, wenn man das Ausgabeordner lässt.

Ich habe zu diesem Zweck auch immer "xcopy" im Postbuild verwendet. Im Zweifelsfall würde ich eine solche Lösung favorisieren. Damit das einfacher, nicht so zentralistisch und nicht manche relativ große Dateien immer wie blöd hin und her kopiert obwohl sich nichts geändert hat, habe ich nur mal einen Custom-Build-Tool geschrieben, das Dateien automatisch als Teil des normalen Builds kopieren können sollte. Ich habe nur im Verdacht das es manche Änderungen stillschweigend ignoriert. Wenn trotzdem Interesse besteht, könnte ich das mal zur Verfügung stellen.

Von DLLs rate ich übrigens ganz allgemein ab. Dynamisches Linken führt zu vielen absolut unnötigen Problemen. Statische Libs sind in den aller meisten Fällen wesentlich einfacher zu handhaben und auf Meldungen im ""XYZ.dll" nicht gefunden"-Stil kann ich als auch jeder Endnutzer gut verzichten. LGPL wäre theoretisch der einzige Grund dagegen, aber diese meidet man am Besten deshalb einfach, es gibt ja zum Glück genug gute Software unter "vernünftiger" Lizenz. (Jedenfalls für Libs...)

Hab ich die Frage falsch verstanden, oder warum hat noch niemand die Option "Copy to Output Directory" vorgeschlagen?

Dazu müssen die Dateien nur Teil des Projektes sein (einfach per Drag and Drop reinschieben) und dann rechtsklick -> Properties -> Copy to Output Directory -> Copy always oder Copy if newer und schon landen die Dateien im Ausgabeverzeichnis.

Das gibt es doch nur bei C#?
Ich habe nie verstanden warum, aber bisher noch keine eingebaute Funktion in dem Stil bei einem C++ Projekt gefunden.

Zitat von »Spiele Programmierer«

Das gibt es doch nur bei C#?

Oh... äh... ja ok wenn das so ist. Hätte eigentlich damit gerechnet, dass das ein universelles Feature von Visual Studio ist

Zitat

Von DLLs rate ich übrigens ganz allgemein ab. Dynamisches Linken führt zu vielen absolut unnötigen Problemen. Statische Libs sind in den aller meisten Fällen wesentlich einfacher zu handhaben und auf Meldungen im ""XYZ.dll" nicht gefunden"-Stil kann ich als auch jeder Endnutzer gut verzichten.

Da hat wohl jemand den Sinn von Dynamic Linking noch nicht verstanden und die Dlls bis jetzt immer falsch gelinkt

Aber ich glaube es wäre auch mal interessant, wenn du dazu einen extra Fred aufmachst. Dann muss das nicht unter der Überschrift "Visual cpluplus 2013 express copy to output" passieren

Ich habe es verstanden und auch schon genutzt. Allerdings nur noch für Plugin-Systeme. Weil dynamisches Linken für andere Zwecke bloß diverse Probleme mit sich bringt. Insbesondere unter C++. Insbesondere das es unterschiedliche Heaps gibt. Das es DLL-Hells gibt. Das es inkompatible DLLs gibt. Und das es Anwendungen bloß nicht unwesentlich größer macht als statische Linkung. Das man den "DLLexport"/"DLLImport"-Präprozessor Schund braucht. Das die DLL gerne mal eine andere Laufzeitversion beansprucht als die Anwendung, wenn man nicht aufpasst. Das man die DLLs an sich verwalten muss als das sie am richtigen Ort sein müssen...
Es hat seine Berechtigung und auch seinen Sinn, den ich meine verstanden zu haben. Tatsächlich machen sich viele alles bloß unnötig kompliziert.

Du würdest dich also auch damit zufrieden geben, wenn es nur Toasts mit Marmelade schon drauf zu kaufen gibt? Und du bist bereit, deinen ganzen Einkauf wegzuschmeißen, nur weil du später merkst, dass die Marmelade angefangen hat zu schimmeln?
Oder andersrum aus der Sicht des Verkäufers: Würdest du wollen, dass deine Kunden zu dir kommen, sich beschweren, dass die Marmelade zu schnell schimmelt und du dann erst überlegen musst, wie du Marmelade haltbarer machst?

Btw.: Dass das 'das' das 'dass' nicht ersetzen kann, das weiß doch jedes Kind.
Btw2.: Ich glaube ein extra Fred ist dafür wirklich sinnvoller