ASP.NET Website DLL: Debug-Version vs. Release-Version

Question

Gibt es beim Hochladen der .dll-Datei meiner ASP.NET-Webanwendung in das /bin/-Verzeichnis meiner Website irgendwelche Nachteile bei der Verwendung der Debug-Version im Gegensatz zur Neukompilierung eines Release-Builds?

Wenn Sie zum Beispiel lokal an der Website arbeiten, ist die Build-Konfiguration auf Debug eingestellt. Wenn alles gut aussieht, gehe ich vor und lade die neueste .dll für die Website/Webapp hoch. Sollte ich stattdessen zu diesem Zeitpunkt die Build-Konfiguration auf Release umstellen, dann kompilieren und dann diese Version der .dll auf den Server hochladen?

Ich hoffe, dass diese Frage nicht doppelt vorkommt. Ich habe eine Reihe anderer Fragen mit ähnlichen Begriffen im Betreff gelesen, aber nichts gefunden, was direkt mit meiner Frage zu tun hat.

Danke,

Adam

Answer 1

Die Ausführung mit Debug-Assemblies ist etwas leistungsintensiver, da sie mehr Speicherplatz beanspruchen, aber normalerweise nicht extrem. Sie sollten ein Release-Build nur dann bereitstellen, wenn es wirklich ein "Release" ist. Wenn Sie immer noch ein gewisses Maß an unerwartetem Verhalten in der freien Wildbahn erwarten, würde ich die Verwendung von Debug-Assemblies in Betracht ziehen, damit Sie mehr nützliche Informationen aus unbehandelten Ausnahmen erhalten. Das eigentliche Performance-"Problem" besteht darin, dass debug="true" in Ihrer web.config.

Answer 2

Vieles hängt davon ab, welche Bedürfnisse Sie haben. Im Allgemeinen lehnen es die Leute ab, den Debug-Build aus Leistungsgründen in die Produktion zu übernehmen. Der ausgegebene Debug-Code ist offensichtlich nicht optimiert und enthält Debug-Symbole, die die Ausführung des Codes verlangsamen können.

Andererseits habe ich schon an Orten gearbeitet, an denen die Richtlinie lautete, Debug-Builds in die Produktion einzubinden, weil es so einfach ist, die Zeilennummer usw. zu sehen, wenn der Code Ausnahmen auslöst. Ich sage nicht, dass ich mit dieser Position einverstanden bin, aber ich habe gesehen, wie es gemacht wurde.

Scott Hanselman hat einen guten Beitrag über eine hybride Version von Debug und Release, die Ihnen das Beste aus beiden Welten bietet aquí .

Answer 3

Wenn Sie eine Website mit geringem Volumen haben, werden Sie die Leistungseinbußen einer Debug-Assembly niemals messbar spüren. Wenn Sie ein hohes Volumen haben, sollten Sie stattdessen andere Mittel zur Protokollierung/Instrumentierung von Code in Betracht ziehen.

Bei einer hochvolumigen Website müssen Sie umfangreiche Stress- und Lasttests durchführen, um zu versuchen, die Anwendung zu zerstören, bevor sie in Produktion geht. Ich würde den ersten Durchgang dieser Tests mit Debug-Assemblies durchführen (da Sie wahrscheinlich etwas kaputt machen werden und es so einfacher ist, zu sehen, wo). Dann wiederholen Sie den Test mit den Release-Assemblies, um sicherzustellen, dass sie sich genauso verhalten wie die Debug-Assemblies.

Answer 4

http://weblogs.asp.net/scottgu/archive/2006/04/11/Don_1920_t-run-production-ASP.NET-Applications-with-debug_3D001D20_true_1D20_-enabled.aspx

Answer 5

Nur sehr wenige Anwendungen werden einen signifikanten Unterschied in der Leistung zwischen Release- und Debug-Builds aufweisen. Wenn Sie eine kleine bis mittelgroße Anwendung betreiben und glauben, dass es Fehler gibt, die Sie noch nicht gefunden haben, verwenden Sie den Debug-Build.