Have you ever wondered what harm does the flag Debug=True brings to your application?
Besides hurting your application's performance in production house, it turns website lifecycle into a vicious circle.
Here is my understanding of using <compilation debug="true" /> on your application's web.config file:
When <compilation debug=”true” /> is switched on within the application’s web.config file, it causes a number of non-optimal things to happen including:
1) You will see a lot more files in Temporary ASP.NET files folder when you use debug=true.
2) Your pages will not timeout when you have debug=“true” which is no an ideal production scenario.
3) Batch compilation will be disabled even if the batch attribute is true in the <compilation> element.
4) The System.Diagnostics.DebuggableAttribute gets added to all generated code which causes performance degradation. Basically, when you have debug=true, the DebuggableAttribute gets added to all generated code.
7) When the debug attribute in the Web.config file is set to true, it generates symbolic information(.pdb information) every time the compiler compiles your .aspx pages as well as disables code optimization. If the application is not being debugged, you should change this attribute to false.
While the debugger is attached and in break mode, no requests to pages in the application execute. Therefore, you should not debug an application on a production Web server while it is in use.
Only one debugger can be attached to the Aspnet_wp.exe process at a time.
The CLR Debugger only debugs managed code, and it only debugs applications on the computer on which the CLR Debugger is running. If you need to debug remotely or if you need to debug code other than managed code, you should use the Visual Studio .NET debugger.
Now, let's see how can you turn OFF this flag at the server level ?
As obvious as this, please use the following configuration feature on the machine.config file:
<configuration> <system.web> <deployment retail=”true”/> </system.web></configuration> You will disable the <compilation debug=”true”/> switch and this will disable the ability to trace output in a page, and turn off the ability to show detailed error messages remotely. Note that these last two items are security best practices you really want to follow (otherwise hackers can learn a lot more about the internals of your application than you should show them).For more information on this, please refer: http://msdn.microsoft.com/en-US/library/ms228298(VS.80).aspx
And, now let us see in what scenario you might want to turn on Debug=True:
ASP.NET supports compiling applications in a special debug mode that facilitates developer troubleshooting. Debug mode causes ASP.NET to compile applications with extra information that enables a debugger to closely monitor and control the execution of an application. Applications that are compiled in debug mode execute as expected. However, the performance of the application is affected. To avoid the effect on performance, it is a good idea to enable debugging only when a developer is doing interactive troubleshooting. By default, debugging is disabled, and although debugging is frequently enabled to troubleshoot a problem, it is also frequently not disabled again after the problem is resolved. So, the best option would be to turn debug=“true,” fix your problem and turn debug=“false” back again.
Please refer following article:http://support.microsoft.com/kb/815157
Because many parts of an ASP.NET application (such as .aspx, .asmx and .ascx pages) are dynamically compiled at run-time, you need to configure the ASP.NET run-time process to compile the application with symbolic information before the application can be debugged. To do this, set the debug attribute in the configuration section of the Web.config file that is located in the root of the application folder to true, as follows:
<configuration> <compile debug=true/></configuration>
Alternatively, you can set the Debug attribute of the Page directive to true in your .aspx pages, as follows:
<%@ Page Debug="true" %>
Let's do a small exercise to illustrate why do we really need to set debug=true in your application's configuration.
Add the following code snippet in Page_Load method of Default.aspx of your sample web application. This code will cause a divide-by-zero(as expected) error message whenever you request the page.
protected void Page_Load(Object sender, EventArgs e)( int32 i = 0; i = i/0;)
Check the output if you have debug="false" (first) and the same page with debug="true" (second) in Code above.
Output when debug="false" [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 Output when debug="true" [OverflowException: Arithmetic operation resulted in an overflow.] _Default.Page_Load(Object sender, EventArgs e) in C:\My Documents\Visual Studio 2010\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 C:\My Documents\Visual Studio 2010 Websites\DebugTrue\Default.aspx.vb:8.
If you are a debugger freak and have some knoweldge about WinDbg dump analysis, you should agree with me in my following notes:
To find out if any of the applications on your server run with debug=true you can run a nifty command in sos.dll called !finddebugtrue which will list out all applications where debug=true in the web.config 0:016> !finddebugtrue Debug set to true for Runtime: 61b48dc, AppDomain: /SampleApplication Debug set to true for Runtime: 1f50e6d8, AppDomain: /MemoryIssues Total 16 HttpRuntime objects And to find out if you forgot to compile some of your assemblies in release mode run !finddebugmodules 0:016> !finddebugmodules Loading all modules. Searching for modules built in debug mode...SampleApplication.dll built debug MemoryIssues.dll built debug fl4sq-9i.dll built debug wepr1t3k.dll built debug r9ocxl4m.dll built debug zmaozzfb.dll built debug
Done Seaching The dlls above with weird 8 character names are the dlls generate when JITing the aspx pages, so they will go away when debug=false.
ScottGu has written an excellent blog on this issue, have a look at the below blog from him:
Have a happy read and share your thoughts.
Let me know if you have any questions and issues on this, I will be happy to answer them.