Don’t run production ASP.NET Applications with debug="true" enabled: ASP Alliance

Print Add To Favorites Email To Friend Rate This Article
Don’t run production ASP.NET Applications with debug="true" enabled

page 1 of 3

Published: 11 Apr 2006

Unedited - Community Contributed

Abstract
In this article, Scott examines how to run an ASP.NET application properly in a production environment.

by Scott Guthrie
Feedback

Average Rating:

Views (Total / Last 10 Days): 42420/ 73

Article Contents:

Introduction

Republished With Permission - Original Article

One of the things you want to avoid when deploying an ASP.NET application into production is to accidentally (or deliberately) leave the <compilation debug="true"/> switch on within the application’s web.config file.

Doing so causes a number of non-optimal things to happen including:

1) The compilation of ASP.NET pages takes longer (since some batch optimizations are disabled)

2) Code can execute slower (since some additional debug paths are enabled)

3) Much more memory is used within the application at runtime

4) Scripts and images downloaded from the WebResources.axd handler are not cached

This last point is particularly important, since it means that all client-javascript libraries and static images that are deployed via WebResources.axd will be continually downloaded by clients on each page view request and not cached locally within the browser. This can slow down the user experience quite a bit for things like Atlas, controls like TreeView/Menu/Validators, and any other third-party control or custom code that deploys client resources. Note that the reason why these resources are not cached when debug is set to true is so that developers don’t have to continually flush their browser cache and restart it every-time they make a change to a resource handler (our assumption is that when you have debug=true set you are in active development on your site).

When <compilation debug="false"/> is set, the WebResource.axd handler will automatically set a long cache policy on resources retrieved via it – so that the resource is only downloaded once to the client and cached there forever (it will also be cached on any intermediate proxy servers). If you have Atlas installed for your application, it will also automatically compress the content from the WebResources.axd handler for you when <compilation debug="false"/> is set – reducing the size of any client-script JavaScript library or static resource for you (and not requiring you to write any custom code or configure anything within IIS to get it).

View Entire Article

(Page 2) »

User Comments

Title: eCommerce Developer
Name: maitreg
Date: 2009-07-23 9:12:20 AM
Comment:
Hmm, ok, our PCI Compliance officer is also telling us we have to disable ASP.NET debug mode on our product server, but then we won't have any reasonable method for actually debugging our live site!! Right now, I've set it up to trap all errors and email me the file name and line # when an error occurs. But with debug mode off, the file name and line # or unavailable!? So now when an error occurs, I only know that "some" error occurred "somewhere". On a complex ASP.NET Web app with 20,000 lines of code (at least half of which may be executed on any given request), debugging is virtually impossible without the debug mode.

And before you ask, anybody who's ever deployed an ASP.NET Web app will tell you that there are 1000s of errors that could occur in a live enironment that did not occur in the development environment.

Isn't there ANY way to safely leave debug mode on? Or is there some way to debug live apps with the debug mode off that I'm unaware of?

Product Spotlight