2009-07-22 5 views
2

Nous avons une solution ASP.Net qui est divisée en plusieurs projets (certains sont des bibliothèques de classes et d'autres sont des sites Asp.Net réels). Une chose qui m'a toujours dérangé est que si les sites ASP.Net et DLL de la bibliothèque de classes sont construits en mode debug, et sont ensuite publiés, web config a changé de sorte que "debug = false" sera la DLL de la bibliothèque de classes en mode de libération?ASP.net, dlls et webconfigs

Si je ne reçois pas de réponse, je vais expérimenter et faire un rapport.

Vive Tony

Répondre

2

Les bibliothèques de classes seront encore déployés en debug, avec les conséquences sur les performances potentielles que vous attendez.

Le site Web dépend du type du projet - s'il s'agit d'un projet de site Web (par exemple, si vous déployez des fichiers .as? X et .cs sur le serveur, ils sont compilés au moment de l'exécution). un effet sur la construction de ces éléments. S'il s'agit d'un projet d'application Web (c'est-à-dire que vous le compilez et déployez le dossier .dll dans/bin ou GAC du serveur), alors cela n'aura aucun effet sur le mode de compilation, comme dans les bibliothèques de classes.

Mais cela va changer la façon dont les pages sont traitées avant d'être envoyées aux utilisateurs.

Scott Guthrie avait un bon poste sur certains de ceci:

Don't run production ASP.NET Application with debug="true" enabled

Tess Ferrandez a également un bon post sur ce sujet:

ASP.NET Memory: If your application is in production… then why is debug=true

+0

Juste ce que je cherchais, un bon Zhaph – TWith2Sugars

1

Le nous Le paramètre b.config <compilation debug=”false” /> (ou true) indique si les symboles de débogage sont injectés dans les assemblages "page" compilés lors de l'exécution. Je crois que cela affecte également la mise en cache des ressources web servies via WebResource.axd.

Ce paramètre n'a rien à voir avec le fait de savoir si l'application a été initialement compilée en tant que version "Release" ou "Debug".

Questions connexes