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

ASP.NET: Check your Web Site today for these common assembly related memory and perf issues

If broken it is, fix it you should — Thu, 13 Apr 2006 01:44:07 GMT

Recently my colleague Doug wrote a nice post on Nine tips for a healthy "in production" ASP.NET application....

Una serie di link sulle performance Asp.Net

PhilloPuntoIt — Thu, 13 Apr 2006 13:33:58 GMT

Interesting Finds

Jason Haley — Thu, 13 Apr 2006 14:16:25 GMT

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

gregor suttie — Thu, 13 Apr 2006 17:44:05 GMT

if yo ugo back and change debug=true to debug=false wont you get a compilation error? do yo need to restart iis after doing this?

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

JConwell — Thu, 13 Apr 2006 18:06:17 GMT

Another slight app startup performance hit you'll have if you set debug to false is that (and i'm guessing here) when the ASP.Net app creates a dll for each aspx page, its not finding a unique base address in memory for each dll. So when the AppDomain loads it will have to spend time rebasing each and every dll into an empty spot in memory. if you only have 3-4 dlls, its much less of a hit.

ASP.NET Performance Checks

Javier G. Lozano — Sat, 15 Apr 2006 21:21:16 GMT

ASP.NET Performance Checks

Javier G. Lozano — Sat, 15 Apr 2006 21:28:45 GMT

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

Tess — Sat, 15 Apr 2006 22:54:33 GMT

Gregor,

You should not get an error message just by changing from debug=true to debug=false, but to avoid having some dlls batch compiled and some not i would recommend deleting the temporary asp.net files when you next IISreset

.NET 点滴

子陵 — Sun, 16 Apr 2006 19:19:11 GMT

ASP.NET Debug=True - Are you guilty?

MrDave's (David Yack) Blog! — Mon, 17 Apr 2006 00:32:43 GMT

Ok &ndash; I admit, I have done this, you take the web.config from development, it gets rolled up to...

<compilation debug="true"></compilation>

Maurizio Tammacco — Tue, 18 Apr 2006 19:31:01 GMT

Uno degli errori più comuni quando si effettua il deployment in ambiente di produzione di una applicazione...

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

Robbie Coleman — Mon, 24 Apr 2006 21:39:26 GMT

We did get an error for a UserControl that it reported it could not load the FileName_ascx class due to multiple versions in the Temp ASP.NET folder.

We identified that we had two user controls with the same file name in diferent Folders of the same Web App. The also had diferent namespaces and never through this exception until we set debug="false". We even wiped the Temp ASP.NET directory clean on an IISreset.

The only way we could fix the error, was by renaming the ascx file of one of the two.

Is this correct...? Was there a better way to fix this?

BTW...
[KissUpText]
Tess, your posts have been very helpfull to our development team, and we really appreciate all the information you have given away.
[/KissUpText]

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

Tess — Tue, 25 Apr 2006 08:56:17 GMT

Hi Robbie,

Thanks for the nice comment:)

I am assuming that you are getting "CS1595: 'UserControls.WebUserControl2' is defined in multiple places; using definition from 'c:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\Temporary ASP.NET Files\usercontrols\293a1a4b\dbb2d387\cisxatg3.dll'
" or similar.

The problem basically occurrs if you are using src rather than CodeBehind and your cs or vb files contain a definition for exactly the same class in exactly the same namespace. The error is really the same as what you would get if you tried to compile a dll with another class defined twice in the same namespace.

The reason i am saying it happens when you use src is because if you would use CodeBehind you would have gotten an error at compile time.

If the usercontrols are really the same I would avoid creating a copy, and instead using the one from the other folder. If they are different I would either give the different names if possible, and if not, make sure that the source classes are in different namespaces, such as ProjectName.FolderName.MyUserControl

The reason you are seeing it now and not before is because you are now batch-compiling everything into one dll.

Hope this helps.

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

erraggy — Tue, 25 Apr 2006 19:17:24 GMT

Thanks Tess,

Sorry, I should have include the exception message:
CS1595: '_ASP.BrokerInformation_ascx' is defined in multiple places; using definition from 'c:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\Temporary ASP.NET Files\root\f4fb459b\4deb68eb\1huxv2vg.dll'

And actually, we are using the CodeBehind attribute:

-------------------------------------------------------------------------
UserControl #1:
<%@ Control Language="c#" AutoEventWireup="false" Codebehind="BrokerInformation.ascx.cs" Inherits="WAB.Websites.GA.UserAdmin.UserControls.BrokerInformation" TargetSchema="http://schemas.microsoft.com/intellisense/ie5"%>">http://schemas.microsoft.com/intellisense/ie5"%>

CodeBehind #1:
namespace WAB.Websites.GA.Admin.UserControls
{
/// <summary>
/// Summary description for BrokerInformation.
/// </summary>
public class BrokerInformation : UserControlBase
...

-------------------------------------------------------------------------

UserControl #2:
<%@ Control Language="c#" AutoEventWireup="false" Codebehind="BrokerInformation.ascx.cs" Inherits="WAB.Websites.GA.Admin.UserControls.BrokerInformation" TargetSchema="http://schemas.microsoft.com/intellisense/ie5" %>

CodeBehind #2:
namespace WAB.Websites.GA.UserAdmin.UserControls
{
/// <summary>
/// Summary description for BrokerInformation.
/// </summary>
public class BrokerInformation : UserControlBase
...

(this is how it looked when the error was happening)

Also, yes they are different controls, and we have since renamed the #2 control AdminBrokerInformation.ascx.

So we are no longer receiving the error, but it looks to me that within a ASP.NET (1.x) application, all aspx and ascx files must be named unique (and not in the FQCN meaning of unique), because they all end up under the same "_ASP.*" namespace.

please let me know if:
Assert.IsTrue(MyCommentAbove.IsCorrect);

Why set the

Vladan Strigo's website - Vladan.Strigo.NET — Fri, 28 Apr 2006 13:09:44 GMT

Ensure that debug is disabled on your production site!

Stefan Goßner — Fri, 28 Apr 2006 16:42:08 GMT

Tess explains in detail why you should never run a production site with debug enabled:

ASP.NET Memory:...

Turn off Debug=true Please!

Technical Weblog of Eric Charran — Sat, 29 Apr 2006 14:42:07 GMT

I always knew that debug=true in the web config of an ASP.NET project was bad karma.&nbsp; However, this...

Derfor skal man IKKE skal have Debug=True i produktion

Michell Cronberg — Sat, 29 Apr 2006 15:09:37 GMT

What problems does leaving debug=true cause

Jan Schreuder on .Net — Sun, 30 Apr 2006 14:55:38 GMT

Every ASP.Net developer knows about this setting, or at least should. But what happens when you forget...

Heie Tips zu ASP.NET

nodomain.cc — Wed, 03 May 2006 15:06:16 GMT

Man lernt doch nie aus. Hier steht warum es uerst schlecht ist, in der web.config einer ASP.NET-Applikation das Flag "debug" auf "true" zu lassen sobald die Applikation produktiv eingesetzt wird.

Weiter finden sich hier Nine tips

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

Markus' Blog — Thu, 04 May 2006 11:36:34 GMT

Warum sollte man&nbsp;debug=false setzen?
http://blogs.msdn.com/tess/archive/2006/04/13/575364.aspx

.NET Resources

mattonsoftware.com — Sat, 06 May 2006 11:30:53 GMT

The following links to .NET resources have been collated over time with the assistance of colleagues.&nbsp;...

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

Blue-fish — Mon, 08 May 2006 10:17:54 GMT

Debug Info. Here's a question: if your application throws an exception which is handled in e.g. Global.asax and written to a file. Will the same ammount of debug information be available with and without debug symbols loaded?

(in my experience it wont. With debug symbols loaded we can e.g. tell exactly which line in which file caused the exception). Very helpful for tracking errors on the production server.

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

Tess — Mon, 08 May 2006 10:25:47 GMT

Hi Blue-fish,

Without the debug symbols you will not get the line and file info, but you seriously have to weigh this against perf and memory issues with running debug=true, or leaving optimization turned off (which is necessary for the symbols to match).

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

Blue-fish — Thu, 11 May 2006 12:45:19 GMT

Right, I know it's a bit controversial to leave your production server running with debug symbols intentionally. However, Considering that the sites I usually build, are cached (public sites with most page requests being cache hits), I think the extra error info justifies the overhead (which i assume is 0 for a cache hit).

Блог баги и отладку

«XOR's Post» — Thu, 11 May 2006 12:56:20 GMT

Рекомендую почитать блог &laquo;If broken it is, fix it you should&raquo;. Детально рассматриваются различные...

Debug=”true” rears it’s ugly head again - Ten Times Better

Debug=”true” rears it’s ugly head again - Ten Times Better — Mon, 15 May 2006 19:09:42 GMT

PingBack from http://tentimesbetter.com/2006/05/15/debugtrue-rears-its-ugly-head-again/

Don’t run production ASP.NET Applications with debug=”true” enabled

ScottGu's Blog — Mon, 22 May 2006 10:50:25 GMT

One of the things you want to avoid when deploying an ASP.NET application into production is to accidentally...

Debug=True in ASP.NET

Niklas Nihl — Mon, 22 May 2006 22:23:11 GMT

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

Shahrouri — Sun, 23 Jul 2006 10:43:06 GMT

I disabled the debug on the production but suddenly the home page stop responding my requests (there is login button when i try to login the page just post back without login to the system), what happened??!!

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

Tess — Wed, 26 Jul 2006 23:20:19 GMT

Only thing I can think of is that disabling debugging generated some type of exception, perhaps because of duplicate class names or similar. I would attach a debugger and try to log in to see if something like that is happening.

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

Jeremy — Thu, 03 Aug 2006 22:02:48 GMT

We set debug=false in our production environment, and this caused the site to crash due to CS1595 [user control] is defined in multiple places. IISReset + wiping the Temp ASP.NET files clears up this error temporarily, but it reoccurs again later if a change is made to the web.config. I've seen all the threads about multiple DLLs, Src vs. CodeBehind, compiler flags, but this is not the cause in our case. We never had this issue until setting debug=false.

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

Tess — Fri, 04 Aug 2006 09:24:59 GMT

Hi Jeremy,

This can also happen if you have multiple virtual directories pointing to the same physical path, in which case there can be a problem like this during re-compilation of the page, because the old dlls don't get removed.

It only happens if batch compilation is set to true, which is why you only see it when debug=true.

You can use this to turn batch compilation off while debug is still set to false, but then you get one dll per page

<compilation defaultLanguage="c#" debug="false" batch="false" />

HTH

How to win friends and improve app performance

How to win friends and improve app performance — Tue, 08 Aug 2006 14:59:01 GMT

PingBack from http://spicycode.com/articles/2006/08/08/how-to-win-friends-and-improve-app-performance

How to win friends and improve app performance

How to win friends and improve app performance — Tue, 08 Aug 2006 14:59:28 GMT

PingBack from http://spicycode.com/articles/2006/05/15/how-to-win-friends-and-improve-app-performance

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

Morgan — Wed, 09 Aug 2006 02:11:07 GMT

Question regarding debug settings in VS 2005... There's a new setting for debug info, pdb-only. How does this compare to full debug info?

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

Tess — Wed, 09 Aug 2006 09:37:58 GMT

Just to avoid confusion (in case there was any:)) setting the app to debug mode in visual studio is different from debug=true

http://msdn2.microsoft.com/en-us/library/8cw0bt21.aspx

With PdbOnly, the dll is still compiled in release mode, but a symbol file is also generated. With debug the dll is not optimized as much as in release mode to allow for injection points for the debugger. However, when you start an application under a managed debugger, the debugger will set attributes on the dlls allowing tracking and less optimization even if the dll is built in release mode, so you will still be able to debug. In an unmanaged debugger this does not happen, unless you do it explicitly with an ini file, but in 98% of the cases that is not important since you dont usually do source stepping anyways with an unmanaged debugger. I would definitely recommend no debug or pdbonly in production.

Having said this, for ASP.NET 2.0 this is only relevant for components used by your Asp.Net pages (not the asp.net pages themselves or the codebehind pages). The compilation model for ASP.NET changed radically from 1.1 to 2.0, where in 1.1 the code behind classes were compiled at design time in visual studio into a dll (stored in the bin directory usually), and in 2.0 it moved over to a different model with several types of compilation strategies and partial classes (see: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvs05/html/Internals.asp). I believe (but don't quote me on this) that if you build from visual studio (visual web developer) you don't really compile into executable dlls anymore, it is merely a pre-check for compilation errors, which means that effectively the release/debug option in visual studio has no effect on the web applications dlls.

The actual compilation occurrs at runtime.

If you have the visual studio help installet you can check out this topic for more info about the new compilation/deployment model
ms-help://MS.VSCC.v80/MS.MSDN.v80/MS.VisualStudio.v80.en/dv_vwdcon/html/3ef36871-2cb9-452a-8c96-2068fccead18.htm

Debug = true in web.config files

www.ChrisMay.org — Thu, 14 Sep 2006 22:28:15 GMT

Sweet sorrow... remote debugging (and more)

A developer's strayings — Sat, 30 Sep 2006 19:42:53 GMT

Continuing from my previous post on common causes for memory leaks, remote debugging is another ASP.NET...

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

Kevin — Tue, 19 Dec 2006 23:02:17 GMT

It sounds like you should always run a production site in Debug=false in the web.config what about running that same site using Dlls that where compiled in debug mode. Do you still run into issues with Debug compiled Dlls?

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

Tess — Wed, 20 Dec 2006 10:27:20 GMT

Hi Kevin,

The timeout and non-batchcompilation is specific to web apps running with debug=true, but you do run into some of the other things i.e. the code is not optimized and there is an overhead on the loader heap for debug true.

Tips for a healthy ASP.NET application in production » Advanced .NET Debugging

Tips for a healthy ASP.NET application in production » Advanced .NET Debugging — Thu, 11 Jan 2007 22:22:03 GMT

PingBack from http://dotnetdebug.net/2006/04/15/tips-for-a-healthy-aspnet-application-in-production/

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

John Garrison — Thu, 18 Jan 2007 12:46:35 GMT

Very good informative article.

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

Carl Johansen — Mon, 12 Feb 2007 07:16:38 GMT

Hi,

I am setting <compilation debug="false"> in Web.config to control my compilation. I am using aspnet_compiler to build my site. Now, my question sounds very simple but I can't seem to find a clear answer to it: does it matter whether I set <compilation debug> to "false" BEFORE or AFTER running aspnet_compiler? I thought that I had figured out that it was necessary to set debug="false" _before_ compiling (makes sense?), but now I am just confused.

If it is important to set debug="false" BEFORE running aspnet_compiler, then I have a follow-up question: why do Visual Studio Web Deployment Projects set it AFTER?! (Have a look at the AspNetCompiler target in Microsoft.WebDeployment.targets).

Thanks v. much.

Error reporting and dw20.exe

Rick Barber's Blog — Thu, 15 Feb 2007 23:57:26 GMT

You may have noticed high CPU usage and sluggish performance on your server before. When you fire up

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

Tess — Mon, 19 Feb 2007 10:19:13 GMT

the debug setting in web.config is only used for jit compilation at runtime so it should be set when you publish your application

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

Tess — Mon, 19 Feb 2007 10:19:46 GMT

the debug setting in web.config is only used for jit compilation at runtime so it should be set when you publish your application

Debug or Release? « public AndreNobre : BlogContext

Debug or Release? « public AndreNobre : BlogContext — Sat, 03 Mar 2007 08:17:46 GMT

PingBack from http://andrenobre.wordpress.com/2007/03/03/debug-or-release/

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

.rip — Sat, 17 Mar 2007 15:46:16 GMT

Hi, Tess

You wrote: "i would recommend deleting the temporary asp.net files when you next IISreset". "Deleting" method integrated in Microsoft(c) Windows, isn't it? Or "delete", in this case, means lowlevel deleting files from disk?

Thanks...

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

Tess — Mon, 19 Mar 2007 10:36:22 GMT

Delete as in deleting the files from disk...

Sweet sorrow... remote debugging (and more)

A developer's strayings — Fri, 30 Mar 2007 13:39:14 GMT

Continuing from my previous post on common causes for memory leaks, remote debugging is another ASP.NET

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

Test — Fri, 22 Jun 2007 21:43:53 GMT

Great it is as easy as just typing !finddebugmodules. Is it really?????? I just learned with lot of disappointment that SOS dll does not have this. I would love to debug and fix if only better information is available to end devolopers

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

test — Fri, 22 Jun 2007 21:45:36 GMT

Also why if retail=true in machine.config still finddebugmodule lists some as debug modules (why doesnt retail=true override everything). why you provide a feature anbd it does not work

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

Tess — Mon, 25 Jun 2007 10:15:15 GMT

It depends on what version of sos.dll you have...

If retail=true then debug=false, but that only means that aspx, asmx, ascx pages will not be built debug.

Any components that you use in your application may still have been built in debug mode, and since that is done prior to jit compiling the application debug=false or retail=true will not, and in my opinion should not override this. That is up to the developer of the individual components to do.

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

Jeff — Wed, 05 Sep 2007 21:29:38 GMT

Changing Debug= "false" in the Web.Config file is causing HTML code generation of an OnClick Event to not generate from the code behind. HTML code is generated for the OnClick Event when Debug= "true" in the Web.Config file.

Here are the code behind .vb statements:

CType(Me.FindControl("btnPrint"), ImageButton).Attributes.Add("OnClick", "return PrintPage();")

CType(Me.FindControl("btnSearchDB"), ImageButton).Attributes.Add("OnClick", "return Search('DivSearch');")

And here are the HTML generated statements:

<TD class="SDToolBarButton"><asp:imagebutton id="btnSearchDB" ImageUrl="..\Images\lens.gif" runat="server" ToolTip="Search Database"></asp:imagebutton><asp:imagebutton id="btnSearchDBDisabled" ImageUrl="../Images/lensDis.gif" runat="server" ToolTip="Search Database"

Visible="False" CssClass="SDToolBarDisabledButton"></asp:imagebutton></TD>

<TD class="SDToolBarButton"><asp:imagebutton id="btnPrint" ImageUrl="..\Images\Print.gif" runat="server" ToolTip="Print Screen"></asp:imagebutton><asp:imagebutton id="btnPrintDisabled" ImageUrl="..\Images\PrintDis.gif" runat="server" ToolTip="Print "

Visible="False" CssClass="SDToolBarDisabledButton"></asp:imagebutton></TD>

It's definitely broke, any ideas on how to fix it?

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

sean — Mon, 10 Sep 2007 13:30:58 GMT

What is sos.dll

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

Tess — Mon, 10 Sep 2007 13:41:20 GMT

sos.dll is an extensions for windbg.exe that allows you to debug managed applications. (Windbg.exe is normally native only) it comes with the framework and you can find it in the framework directory.

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

Renata — Tue, 09 Oct 2007 09:16:23 GMT

Hi, I read your and Scott's blog, and can't find a solution to the HTTPS problem. That is when using asp:menu control, users in IE6 get a "security" warning on EVERY mouse over action, as it's trying to call the WebResource.axd file.

Is this a symptom of debug=true, or something else?

Renata

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

Tess — Tue, 09 Oct 2007 10:17:45 GMT

It is not a symptom of using debug=true, assuming that you get "This page contains both secure and non-secure items. Do you want to display the non secure items"

It has to do with the menuitem populating the context menu from an HTTP resource.

Check this post out on how to fix it...

http://blogs.msdn.com/jorman/archive/2006/02/06/nonsecure-items-message-using-menu-control-over-ssl.aspx

Thanks

Tess

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

Jay — Fri, 19 Oct 2007 19:18:18 GMT

When are the commands (!finddebugmodules and !finddebugtrue) going to be available for the ASP.NET 2.0?

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

Tess — Mon, 22 Oct 2007 09:11:52 GMT

I wish I knew

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

Chris Carter — Wed, 24 Oct 2007 21:08:12 GMT

OK,

I'm in a debate and I need to "see" and "touch" what exactly occurs when debug="true" in a web application project.

Another developer building an ASP.NET 2.0 Web Application Project, claims that that debug="true" was causing a page to run slow. The page has a code that does a file upload.

I put together a sample web application project(note, not an asp.net web site), and using build scripts, build and deploy to two different virtual directories, one with debug="true" and one with debug="false".

Poking around the asp.net temp files directory I found the munged code file plus the assembly that was generated. Using Reflector, Beyond Compare, and ILDASM, there are no differences in the output.

My question is, is the debug="true" only something that asp.net websites worry about and not web application projects? if not, then what does debug="true" actually do? because I can't see where it stuck in anything more or less than when it was set to "false".

TIA,

Chris

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

Tess — Thu, 25 Oct 2007 09:39:30 GMT

HI Chris,

I dont think you will find anything else either, because i dont know how debug=true or false would affect a fileupload.

Not exactly sure what you mean by web app projects vs. asp.net web sites but assuming you mean "building the app in vs.net" vs. "compilation that occurrs at runtime" then the answer is that building a web app in vs.net (in 2.0) is mostly a sanity check, to my knowledge no actual code is being compiled (unless you have separate classes in the project). The only thing that matters is debug=true/false, since this affects how the pages get jitted (along with all the other stuff mentioned in the post)

I do seem to remember though that if you set the release mode to debug or release that will change the debug setting in web.config, but I can't say for sure.

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

Martin Kulov — Sun, 28 Oct 2007 20:51:38 GMT

Hi Tess,

I can not find !finddebugtrue and !finddebugmodules commands in SOS.dll for ASP.NET 2.0. It seems that SOS has fewer commands in this version of .NET framework.

How we can see which modules are built with debug="true" using some manual steps or other commands?

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

Martin Kulov — Sun, 28 Oct 2007 21:18:26 GMT

I guess that would be the lm command. Thanks anyway :)

Lucascan's top 5 tips for a healthy ASP.NET application

Solving the world's problems, one support incident at a time... — Mon, 07 Jan 2008 03:42:01 GMT

These tips are reasonably well-known and have been blogged by others. However, considering how often

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

Mojtaba — Thu, 22 May 2008 07:14:59 GMT

that was fantastic.i though before that making debug = false will have effect even after we compile the app.

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

Tess — Thu, 22 May 2008 09:17:03 GMT

it does, debug=false is for the JITing

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

Thomas — Wed, 14 Jan 2009 00:29:22 GMT

Tess Ferrandez is a hottie ~!!!

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

Vladan — Fri, 03 Apr 2009 02:48:15 GMT

I did machine.config change on WFEs in MOSS 2007. I am not sure if it's a good idea do it in MOSS but it seems to have made my site stable. Granted it may impact MOSS logging, but if I have to choose stability over functionality, stability takes the cake :).

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

G. Vijay Bhargav — Mon, 08 Jun 2009 07:56:48 GMT

Can u explain about sos.dll & how to use the !finddebugtrue... commands.

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

Kundan — Mon, 29 Jun 2009 17:45:23 GMT

Publishing a application compiles it to assemblies. Do we still need debug="false" in the web.config in this scenario.

I would like your advice on the changes to this in .net 2.0.

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

Tess — Mon, 29 Jun 2009 23:14:49 GMT

By default debug=false in 2.0. Wether you need to set it to true or not depends on if your app is pre-compiled or not, but really, there is no reason for not turning debug=true in production.

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

Jackie — Wed, 15 Jul 2009 20:44:53 GMT

Yes, but what about the ajaxtoolkit .dlls that have debug set to true?

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

Tim — Wed, 23 Dec 2009 13:03:57 GMT

Hello Tess

Sorry to resurrect this old zombie issue, but ...

I notice in your article you make no mention of .asmx web services. Does this setting have as big an effect on these too? I'm trying to investigate a performance issue on a middle-tier web server that exclusively hosts .asmx web services which are implemented as C# dll's. I think what I'm not sure about :D is whether this setting affects the JIT/runtime compilation of the web service's MSIL objects (i.e. the dll's) and therefore presumably will affect the performance/memory usage of these web services too, or is it just the assembly of those web-app pages and 'code-behind' *.aspx.vb/vc ... er ... things.

Hopefully you can make a sensible question out of this :)

thanks

Tim

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

ASP.NET: Check your Web Site today for these common assembly related memory and perf issues

Una serie di link sulle performance Asp.Net

Interesting Finds

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

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

ASP.NET Performance Checks

ASP.NET Performance Checks

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

.NET 点滴

ASP.NET Debug=True - Are you guilty?

&lt;compilation debug=&quot;true&quot;&gt;&lt;/compilation&gt;

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

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

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

Why set the

Ensure that debug is disabled on your production site!

Turn off Debug=true Please!

Derfor skal man IKKE skal have Debug=True i produktion

What problems does leaving debug=true cause

Heie Tips zu ASP.NET

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

.NET Resources

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

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

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

Блог баги и отладку

Debug=”true” rears it’s ugly head again - Ten Times Better

Don’t run production ASP.NET Applications with debug=”true” enabled

Debug=True in ASP.NET

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

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

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

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

How to win friends and improve app performance

How to win friends and improve app performance

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

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

Debug = true in web.config files

Sweet sorrow... remote debugging (and more)

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

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

Tips for a healthy ASP.NET application in production » Advanced .NET Debugging

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

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

Error reporting and dw20.exe

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

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

Debug or Release? « public AndreNobre : BlogContext

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

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

Sweet sorrow... remote debugging (and more)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Lucascan's top 5 tips for a healthy ASP.NET application

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

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

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

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

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

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

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

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

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

<compilation debug="true"></compilation>