The Infamous Debug=True Attribute in ASP.NET: ASP Alliance

Print Add To Favorites Email To Friend Rate This Article
The Infamous Debug=True Attribute in ASP.NET

page 8 of 9

by Rahul Soni
Feedback

Average Rating:

Views (Total / Last 10 Days): 60534/ 235

Article Contents:

What do you lose with debug="false"

Now having said all the problems with debug=true, I must say that there is a good side to debug=true as well. So, what do you actually lose by setting debug=false?

To show this I have added the following code in Page_Load method of Default.aspx. This code will cause an error message whenever you request the page.

Listing 9

Protected Sub Page_Load(ByVal sender As Object, _
ByVal e As System.EventArgs) Handles Me.Load
Dim x As Integer
  x = 0
  x = x / 0
End Sub

Check the output if you have debug="false" (first part of the code) and the same page with debug="true" (second half of the code) in Listing 10.

Listing 10 – Bad Code causing Overflow Exception

 [OverflowException: Arithmetic operation resulted in an overflow.]
   _Default.Page_Load(Object sender, EventArgs e) +18
   System.Web.UI.Control.OnLoad(EventArgs e) +99
   System.Web.UI.Control.LoadRecursive() +47
   System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint,
     Boolean includeStagesAfterAsyncPoint) +1061

 
 
 
 [OverflowException: Arithmetic operation resulted in an overflow.]
   _Default.Page_Load(Object sender, EventArgs e) in I:\My Documents\Visual 
     Studio 2005\WebSites\DebugTrue\Default.aspx.vb:8
   System.Web.UI.Control.OnLoad(EventArgs e) +99
   System.Web.UI.Control.LoadRecursive() +47
   System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint,
     Boolean includeStagesAfterAsyncPoint) +1061

Notice that with debug=“true” you get a more detailed stack output and it even tells you that the problem happened on line number 8 in a page located at I:\My Documents\Visual Studio 2005\Websites\DebugTrue\Default.aspx.vb:8.

But, do you honestly think that getting this detailed error message with debug=true outweighs the performance gain with debug=false? If there is a scenario where you would answer YES, I would suggest you go ahead turn debug=“true,” fix your problem and turn debug=“false” back again.

« (Page 7)

View Entire Article

(Page 9) »

Article Feedback

Comment:
Title:
Name:
Url:	( Optional )

Please add 6 and 3 and type the answer here:

User Comments

Title: SS
Name: SS
Date: 10/3/2010 7:34:45 AM
Comment:
Really a commedable effort for compiling all this in one article..

Title: The Honorable Lord
Name: Confused
Date: 12/22/2009 2:27:19 PM
Comment:
Sorry, the latest version of my post is the one to keep the older one can be discarded.

Title: The Honorable Lord
Name: Confused
Date: 12/22/2009 2:08:55 PM
Comment:
.
WINDOWS 7, VS 2008, IIS 7.5
Beautiful write-up. Saved me the time to do it myself.

But, confused: I still do not understand the realtionship betweent he web.config debug= switch and the Configuration Manager setting to Release/Debug ?

I keep 2 separate web.config files one for the HOST one for the dev machine.

My web.config on the HOST is set to debug=false.
I never have had need to compile on the HOST(I wonder if some scenarios require that! ...besides having to DEBUG on HOST for some reason.)
_______________________________________________________
My web.config on the development machine is set to debug=true.
If I set it to false... and attempt to DEBUG... I get prompted to allow the IDE to change it to true for me...
I let it make the change and all is good, I am now allowed to debug.
ok, so far so good.

What I am confused about is the setting in the Configuration Manager(under BUILD option in VS). It is set to Release.
In my old WIN XP Pro dev env, I had to set that to DEBUG to be able to debug. In this new version, I leave it as Release.

So, when I compile(on dev machine)[dll version I will put on the HOST] I find myself making sure the debug= in the web.config is set to false.

Since the Configuration Manager setting is Release... should I not be able to simply leave the debug=true in the web.config on dev machine? Thus satisfying the benefit of avoiding to have to constantly change the setting?

Thus by implication it would mean the debug= switch in the web.config affects JIT only?

2 Notes:
- no matter how I set debug in either or both web.config or configuration manager, I get a pdb file.
- The Configuration Manager option under BUILD will not show until you visit the options and turn it on, on the latest version of VS <- what I nightmare that was to figure out.
.

Title: Pretty good
Name: Anand
Date: 11/25/2009 11:58:15 PM
Comment:
Pretty good and detailed. We are working on perf issues on a project. This helps a lot. Thanks.

Title: Web Developer
Name: Raghav Khunger
Date: 4/11/2009 12:51:42 PM
Comment:
Superb Article !!!!!!!!Great Explanation Rahul.

Title: For Gurpiar Singh
Name: Rahul Soni
Date: 8/1/2008 6:24:59 PM
Comment:
Your assumption is correct Gurpriar. This article mainly talks about the JIT.

There is a pretty neat feature in .NET 2.0 which talk about deployment retail="true" which is supposed to be set in Machine.Config file and that would ensure the .NET Runtime will assume as if debug="false" in all the web.config.

http://msdn.microsoft.com/en-us/library/ms228298.aspx

Hope that helps,
Rahul

Title: Software Architect
Name: Gurpiar Singh
Date: 8/1/2008 6:05:52 PM
Comment:
We do have debug = false set in web.config on production servers
But we have debug=true set in web.config on Build Machine, where code gets compiled for deployment

And we compile code using MSBuild, with Configuration set to release mode.

The way our Continuous Integration is set up, there is no easy way for us to set this flag to false when code is getting compiled.

So, I am assuming your post applies only while the code is getting deployed and running in production, and not when code actually gets compiled.

Title: Webserver Optimization
Name: Venkatesh R
Date: 5/12/2008 4:00:33 AM
Comment:
Thanks a ton for the Clear explanation. This Issue causing not only the application but the server resource utilization.

Title: For Milan
Name: R S
Date: 8/22/2007 11:11:48 AM
Comment:
Hi Milan,

Thanks for your comments.

Precompiled websites are a way to deploy. Notice that you deploy the application under a folder, but not in the Temporary ASP.NET folder. So, although the website is already compiled, it is NOT JIT compiled.

To know more about JIT, you can visit...
http://msdn.microsoft.com/msdnmag/issues/05/05/JITCompiler/default.aspx

Title: how about precompiled site
Name: mILAN
Date: 8/22/2007 4:03:12 AM
Comment:
How about precompiled websites (in .NET 2)? Since the website is already compiled, I don't think the case is same? Am I correct?

Title: For Craig
Name: R S
Date: 8/21/2007 7:12:10 PM
Comment:
Hi Craig,

Thanks for your comments. I just wanted to confirm whether you are getting errors when Debug=True? If you are setting it to true, why?

Also, what is the complete error message you get. Do you see anything in the EventLogs?

Title: Why do I have issues when I do Debug=True
Name: Craig
Date: 8/21/2007 7:08:40 PM
Comment:
Thanks for the article. I modified all the web.configs on my server and everything really starts blowing up. Mostly COM+ errors that reset W3WP.exe. Obviously, this is very bad for our customers. Why would this work fine when debug=false? Is there some underlying problem in our code that is being exposed?

Title: The Infamous Debug=True Attribute in ASP.NET
Name: .rip
Date: 8/18/2007 5:01:36 AM
Comment:
Great article!!!

Title: The Infamous Debug=True Attribute in ASP.NET
Name: Sojesh
Date: 8/15/2007 2:02:47 PM
Comment:
Amazing stuff Rahul! Thanks for such a nice article showcasing every possible piece of information about the topic.... as usual!

Title: The Infamous Debug=True Attribute in ASP.NET
Name: Dan
Date: 8/2/2007 6:19:00 AM
Comment:
This article is absolutely fantastic, MANY thanks :)

Title: The Infamous Debug=True Attribute in ASP.NET
Name: Saurabh
Date: 8/1/2007 11:11:39 AM
Comment:
This is unarguably the best article i have read on "Debug=true" issue. The depth to which Rahul has gone to explain the repercussions of having debug set to true shoes his expertise and command over the subject.
Excellent job done! A must read for any Asp.Net enthusiast.

Saurabh

Product Spotlight