DLL de site Web ASP.NET: version de débogage et version

Question

Lors du téléchargement de mon fichier .dll d'application Web ASP.NET sur le répertoire/bin/de mon site Web, l'utilisation de la version de débogage présente des inconvénients par rapport à la recompilation d'une version. Par exemple, lorsque vous travaillez localement sur le site Web, la configuration de construction est définie sur Déboguer. Lorsque les choses semblent bonnes, je vais de l'avant et télécharger le dernier fichier .dll pour le site Web/webapp. Devrais-je à la place passer la configuration de construction à Release, puis compiler, puis télécharger cette version du fichier .dll sur le serveur?

J'espère que cette question n'est pas un doublon. J'ai lu un certain nombre d'autres questions avec des mots similaires dans le sujet, mais n'a pas trouvé quelque chose directement lié à ma question.

Merci,

Adam

Answer 1

L'exécution avec des assemblages de débogage est un peu plus lourde en termes de performances, car ils consomment plus de mémoire, mais généralement pas de façon extrême. Vous devriez seulement déployer une version de version quand c'est vraiment une "version". Si vous anticipez toujours un certain niveau de comportement inattendu dans la nature, je considérerais d'utiliser des assemblys de débogage, de sorte que vous obtiendrez plus d'informations utiles à partir d'exceptions non gérées. La vraie performance "gotcha" est d'avoir debug="true" dans votre web.config.

Answer 2

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 3

Beaucoup de cela dépend de ce que vos besoins sont. En général, les gens désapprouvent la mise en production de la version de débogage pour des raisons de performances. Le code de débogage émis n'est apparemment pas optimisé et contient des symboles de débogage qui peuvent ralentir l'exécution du code. D'autre part, j'ai travaillé sur des lieux où la politique consistait à mettre les builds de débogage en production, car il est facile de voir le numéro de ligne, etc., quand le code lance des exceptions. Je ne dis pas que je suis d'accord avec cette position, mais j'ai vu des gens le faire. Scott Hanselman a un bon article sur faire une version hybride de Debug and Release qui pourrait vous obtenir le meilleur des deux mondes here.

Answer 4

Très peu d'applications vont voir une différence significative dans les performances entre la version et les versions de débogage. Si vous exécutez une application de taille petite à moyenne et que vous pensez qu'il y a peut-être des bogues que vous n'avez pas détectés, utilisez la version de débogage.

Answer 5

Si vous avez un site Web à faible volume, vous ne verrez jamais la pénalité de performance d'un ensemble de débogage de façon mesurable. Si vous avez un volume élevé, recherchez plutôt d'autres moyens de consignation/code d'instrumentation. Sur un site Web à grand volume, vous devez effectuer des tests de contrainte et de charge très poussés pour tenter de briser l'application avant sa mise en production. Je ferais la première passe de ce test avec les assemblages de débogage (puisque vous allez probablement décomposer des choses, et cela vous aidera à voir où). Ensuite, répétez avec les assemblys Release pour vous assurer qu'ils se comportent de la même manière que ceux de Debug.