Hi, wenn ich ein Programm in Release- bzw.Debug-Konfiguration erstelle, werden die beiden Verzeichnisse BIN und OBJ angelegt. Im BIN-Ordner gibt's dann die Unterverzeichnisse Debug und Release, im Order OBJ gibt's den x86-Ordner und dann jeweils Debug- und Release-Ordner. Die Frage ist nun, was sind die Unterschiede bzw. aus welchem Ordner zieht man die "endgültige/offizielle" Variante? Bei den Release-Varianten fehlt jeweils die PDB-Datei, welche für Debuginfos zuständig ist. In den jeweiligen Verzeichnissen des OBJ-Ordners befinden sich zusätzlich noch die Dateien "ResolveAssemblyReference.cache" und "<ProjectName>.csproj.FileListAbsolute.txt". Ich finde es etwas verwirrend, vielleicht kann jemand Licht ins Dunkel bringen :) Ralf
Ralf schrieb: > Hi, > > wenn ich ein Programm in Release- bzw.Debug-Konfiguration erstelle, > werden die beiden Verzeichnisse BIN und OBJ angelegt. > Im BIN-Ordner gibt's dann die Unterverzeichnisse Debug und Release, im > Order OBJ gibt's den x86-Ordner und dann jeweils Debug- und > Release-Ordner. > > Die Frage ist nun, was sind die Unterschiede bzw. aus welchem Ordner > zieht man die "endgültige/offizielle" Variante? BIN auf jeden Fall. > Bei den Release-Varianten fehlt jeweils die PDB-Datei, welche für > Debuginfos zuständig ist. Nur weil die Optionen so eingestellt sind, man könnte auch fürs Release-Build Debuginfos erstellen lassen, ist auch oft sinnvoll. > In den jeweiligen Verzeichnissen des OBJ-Ordners befinden sich > zusätzlich noch die Dateien "ResolveAssemblyReference.cache" und > "<ProjectName>.csproj.FileListAbsolute.txt". > > Ich finde es etwas verwirrend, vielleicht kann jemand Licht ins Dunkel > bringen :) Das OBJ-Verzeichnis ist für temporären Kram, wird wohl auch für C++ viel mehr benutzt als für C#. Ignorier es einfach.
> BIN auf jeden Fall. > ... > Das OBJ-Verzeichnis ist für temporären Kram, wird wohl auch für C++ viel > mehr benutzt als für C#. Ignorier es einfach. Okay, danke für die Info. > Nur weil die Optionen so eingestellt sind, man könnte auch fürs > Release-Build Debuginfos erstellen lassen, ist auch oft sinnvoll. Aber... isses dann nicht das gleiche? Obwohl... es wäre die code-optimierte Variante mit Debuginfos, richtig? Aber was bringen die Debuginfos auf einem System auf dem kein Debugger installiert ist? Oder wird die Ausgabe, die man beispielsweise mit "debug.println" macht dann irgendwo anders hin umgeleitet, beispielsweise in eine Datei? Ralf
Ralf schrieb: >> Nur weil die Optionen so eingestellt sind, man könnte auch fürs >> Release-Build Debuginfos erstellen lassen, ist auch oft sinnvoll. > Aber... isses dann nicht das gleiche? Obwohl... es wäre die > code-optimierte Variante mit Debuginfos, richtig? Genau. Macht beim Debuggen dann auch "interessante" Effekte, weil der Compiler beim Optimieren gern Code-Blöcke umarrangiert. Trotzdem besser als ohne Debuginfos. > Aber was bringen die Debuginfos auf einem System auf dem kein Debugger > installiert ist? Nix, der Kunde soll ja nicht debuggen und bekommt die Debuginfos auch nicht mitgeliefert. > Oder wird die Ausgabe, die man beispielsweise mit > "debug.println" macht dann irgendwo anders hin umgeleitet, > beispielsweise in eine Datei? Nein, das wäre dann doch zu viel Magie. Es geht einfach darum dass man das an den Kunden gegebene Binary (eine garantiert bitgenaue Kopie) selber debuggen kann falls schwierige Probleme nachvollzogen werden müssen, das muss also aufgehoben werden.
> Genau. Macht beim Debuggen dann auch "interessante" Effekte, weil der > Compiler beim Optimieren gern Code-Blöcke umarrangiert. Trotzdem besser > als ohne Debuginfos. Oh ja, das hab ich bei den µC-Compilern schon erlebt, dass die Release-Variante mit voller Optimierung etwas so verbogen hat das nix mehr lief :) > Nix, der Kunde soll ja nicht debuggen und bekommt die Debuginfos auch > nicht mitgeliefert. > ... > Es geht einfach darum dass man das an den Kunden gegebene Binary (eine > garantiert bitgenaue Kopie) selber debuggen kann falls schwierige > Probleme nachvollzogen werden müssen, das muss also aufgehoben werden. Da stimme ich dir zu, die Kopie mit Debug-Infos macht Sinn. Aber in dem Zusammenhang würde mich interessieren, wie man dann vorgeht wenn man das Problem nicht am Entwicklungsrechner nachvollziehen kann, da das Problem vielleicht lokal auf den Kunden beschränkt ist. Gibts da ne Möglichkeit trotzdem an die Debugausgaben o.ä. ranzukommen? Ansonsten würd ich mir ne eigene Debugklasse schreiben, welche anstatt der Debugkonsole eine TXT-Datei o.ä. für die Ausgaben verwendet. Ein-/Ausschalten kann man die Ausgaben ja dann über einen versteckten Switch oder so. Ralf
Ralf schrieb: >> Genau. Macht beim Debuggen dann auch "interessante" Effekte, weil der >> Compiler beim Optimieren gern Code-Blöcke umarrangiert. Trotzdem besser >> als ohne Debuginfos. > Oh ja, das hab ich bei den µC-Compilern schon erlebt, dass die > Release-Variante mit voller Optimierung etwas so verbogen hat das nix > mehr lief :) > >> Nix, der Kunde soll ja nicht debuggen und bekommt die Debuginfos auch >> nicht mitgeliefert. >> ... >> Es geht einfach darum dass man das an den Kunden gegebene Binary (eine >> garantiert bitgenaue Kopie) selber debuggen kann falls schwierige >> Probleme nachvollzogen werden müssen, das muss also aufgehoben werden. > Da stimme ich dir zu, die Kopie mit Debug-Infos macht Sinn. > Aber in dem Zusammenhang würde mich interessieren, wie man dann vorgeht > wenn man das Problem nicht am Entwicklungsrechner nachvollziehen kann, > da das Problem vielleicht lokal auf den Kunden beschränkt ist. Dann hat man in jedem Fall ein größeres Problem am Hals... ;-) > Gibts da ne Möglichkeit trotzdem an die Debugausgaben o.ä. ranzukommen? > Ansonsten würd ich mir ne eigene Debugklasse schreiben, welche anstatt > der Debugkonsole eine TXT-Datei o.ä. für die Ausgaben verwendet. > Ein-/Ausschalten kann man die Ausgaben ja dann über einen versteckten > Switch oder so. Wenn ich davon ausgehe dass Du .NET (C#, VB.NET, ...) benutzt ist in jedem Fall "Log4net" das Mittel der Wahl. Gibt es wohl auch für C++, habe ich aber noch nichts damit gemacht. Da sind solche Features halt schon drin, haben ja auch andere Leute dieselben Probleme.
> Dann hat man in jedem Fall ein größeres Problem am Hals... ;-) grins =) Wenn's einfach wär, könnt's jeder XD > Wenn ich davon ausgehe dass Du .NET (C#, VB.NET, ...) benutzt ... Korrekt. > ...ist in jedem Fall "Log4net" das Mittel der Wahl. Gibt es wohl auch für > C++, habe ich aber noch nichts damit gemacht. Log4Net hört sich gut an, nachdem was ich beim Überfliegen gelesen habe -> besten Dank für den Tip. Ralf
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.