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


Statement

 

“Ensure that the debug=”false” on the <compilation> element in the web.config file of each and every ASP.NET application on the server. The default during development is “true” and it is a common mistake to allow this development time setting to find its way onto production servers during deployment. You don’t need it set to true in production and it often leads to memory overhead and inefficiencies.”

 

What problems does leaving debug=true cause?

 

There are three main differences between debug=true and debug=false:

 

  1. ASP.NET Timeouts

  2. Batch compilation

  3. Code optimization

 

ASP.NET Timeouts

 

When debug is set to true, asp.net requests will not time out. This is to allow you to debug with visual studio at your own pace without having to worry about the requests suddenly disappearing. Of course in a production environment timeouts are crucial to avoid for requests to be stuck indefinitely, so this is reason #1 to make sure debug is set to false when the application is deployed into production.

 

Batch compilation

 

In short, when debug=true, we don’t batch compile, when debug=false we do…

 

What does this mean? 

 

When an aspx, asax, or ascx page is first requested it gets compiled into an assembly. This assembly has a name like 3ks0rnwz.dll or similar (8 characters) and stores the class for the actual ascx, asax, or aspx page (not the code behind).  The assembly goes into a folder in the C:WINDOWSMicrosoft.NETFrameworkv1.1.4322Temporary ASP.NET Files with the same name as the application.

 

The code behind class gets compiled into the main dll for the assembly, and it along with all the other dlls in the applications bin directory get shadow copied to the Temporary ASP.NET files.

 

Back to the 3ks0rnwz.dll… If we have debug=true, we create one dll per aspx, asax, or ascx page and this dll is compiled in debug mode, so if you have 100 web pages, you will have 100 assemblies, and they are generated as the pages are requested.

 

If we instead have debug=false, we batch compile, which means that the first time you request any page in your application, we compile the whole batch into one big assembly. This is a truth with some modification.  The user controls (ascx pages) are compiled into a separate assembly from the aspx pages and the aspx pages are compiled in groups based on what other files (read usercontrols) they include. The global.asax is also compiled separately.  And batch compilation occurs on a directory bases, meaning that if your application has subdirectories, the subdirectories are compiled separately to avoid for example name clashes, as it is valid to have two aspx pages with the same name in different directories. But all in all, instead of 100 dlls, you might end up with 3 or 4.

 

Ok, big deal? It’s the same code so the size of the combined assemblies shouldn’t much differ from the size of the individual assemblies right?  Truth is, there probably isn’t an enormous difference. But… and this is a big but… there is overhead for each dll, and if the dll is compiled in debug mode there is overhead for items needed for debugging, and … last but not least (in fact probably most important), the assemblies won’t be laid exactly side by side, so with a large number of assemblies you start fragmenting the virtual address space making it harder and harder to find large enough spaces to store the managed heaps, potentially causing out of memory exceptions. 

 

One caution even if you have debug=false, is that if you go in and change something in one of your aspx pages, this page will have to be recompiled, but this doesn’t cause an appdomain reload so the whole application is not batch compiled again.  This has the effect that the page will now get recompiled separately and get its own dll, so don’t change your aspx pages on a live server too often. 

 

There is a setting in machine.config determining how many recompiles are allowed before the app domain restarts, by default it is set to 15, so after 15 recompilations the app domain will restart, just as it would if you touched the web.config or touched the bin directory.  

 

Code optimization

 

In order to be able to step through code line by line the JITter can’t really optimize the code which means that your debug dlls will be less performant than if they were compiled in release mode.

 

So as you can probably figure, there is a large benefit to having debug=false in production…

 

How can you identify it in a memory dump?

 

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, now how easy is thatJ

 

0:016> !finddebugtrue

Debug set to true for Runtime: 61b48dc, AppDomain: /MyDebugApplication

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…

 

MyDebugApplication.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.

 

 

Oh, before I forget… when you change from debug=true to debug=false it is a good idea to clean out your Temporary ASP.NET files for this application so you don’t have some old junk in there causing it to still not batch compile.

 

 

In ASP.NET 2.0 there is a switch that can be turned on in machine.config that turns off all debug=true, so in 2.0 applications you can do this directly without worrying about finding out which applications do and don’t have it.

 

<configuration>

    <system.web>

          <deployment retail=”true”/>

    </system.web>

</configuration>

 

If you want some more goodies about debug=true, read ScottGu’s blog post about it http://weblogs.asp.net/scottgu/archive/2006/04/11/442448.aspx

 

 

 

 






Comments (87)

  1. Recently my colleague Doug wrote a nice post on Nine tips for a healthy &quot;in production&quot; ASP.NET application….

  2. gregor suttie says:

    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?

  3. JConwell says:

    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.

  4. Tess says:

    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

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

  6. Uno degli errori pi&#249; comuni quando si effettua il deployment in ambiente di produzione di una applicazione…

  7. 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]

  8. Tess says:

    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:WINDOWSMicrosoft.NETFrameworkv1.1.4322Temporary ASP.NET Filesusercontrols293a1a4bdbb2d387cisxatg3.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.

  9. erraggy says:

    Thanks Tess,

    Sorry, I should have include the exception message:

    CS1595: ‘_ASP.BrokerInformation_ascx’ is defined in multiple places; using definition from ‘c:WINDOWSMicrosoft.NETFrameworkv1.1.4322Temporary ASP.NET Filesrootf4fb459b4deb68eb1huxv2vg.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&quot;%>”>http://schemas.microsoft.com/intellisense/ie5&quot;%>

    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&quot; %>

    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);

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

    ASP.NET Memory:…

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

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

  13. nodomain.cc says:

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

    Weiter finden sich hier Nine tips

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

  15. Blue-fish says:

    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.

  16. Tess says:

    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).  

     

  17. Blue-fish says:

    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).

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

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

  20. Shahrouri says:

    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??!!

  21. Tess says:

    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.

  22. Jeremy says:

    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.

  23. Tess says:

    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

  24. Morgan says:

    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?

  25. Tess says:

    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

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

  27. Kevin says:

    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?

  28. Tess says:

    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.

  29. John Garrison says:

    Very good informative article.

  30. 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.

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

  32. Tess says:

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

  33. Tess says:

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

  34. .rip says:

    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…

  35. Tess says:

    Delete as in deleting the files from disk…

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

  37. Test says:

    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

  38. test says:

    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

  39. Tess says:

    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.

  40. Jeff says:

    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="..Imageslens.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="..ImagesPrint.gif" runat="server" ToolTip="Print Screen"></asp:imagebutton><asp:imagebutton id="btnPrintDisabled" ImageUrl="..ImagesPrintDis.gif" runat="server" ToolTip="Print "

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

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

  41. sean says:

    What is sos.dll

  42. Tess says:

    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.

  43. Renata says:

    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

  44. Tess says:

    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

  45. Jay says:

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

  46. Tess says:

    I wish I knew

  47. Chris Carter says:

    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

  48. Tess says:

    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.

  49. Martin Kulov says:

    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?

  50. Martin Kulov says:

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

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

  52. Mojtaba says:

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

  53. Tess says:

    it does, debug=false is for the JITing

  54. Thomas says:

    Tess Ferrandez is a hottie ~!!!

  55. Vladan says:

    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 :).

  56. G. Vijay Bhargav says:

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

  57. Kundan says:

    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.

  58. Tess says:

    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.

  59. Jackie says:

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

  60. Tim says:

    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 😀 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

  61. Krister says:

    Do you have any general benchmarks on how much smaller the memory footprint can be if debug mode = false? Are we talking 50% more memory, twice as much memory, or more?

    I understand that the answer is "It depends on your app", but do you have any rules of thumb. We’ve got a pretty complex app with hundreds of thousands of lines of code.

    We would prefer to keep the debug info in there because we’re concerned about the effort to retest the app and side effects it would have on our support team, who are used to using the debug info to resolve customer cases.

    On the other hand, our app has a huge memory footprint.  If the compile in release mode is going to reduce it by 50% or more, then we may need to look into it.

    Thanks in advance

  62. Tess says:

    Hi Krister,

    There is really no good way to say.  Picture this… if you have 20 pages = 20 assemblies, and then your app allocates 1 GB worth of memory for various datasets etc. then the overhead for the debug data for the 20 assemblies would be negligeable.  If on the other hand you have 1000 assemblies/pages and your app is otherwise frugal with memory usage then the overhead is not so negligeable so it is really impossible to say.   Even on a specific page/assembly you can’t give a percentage, and it also depends on if the page is changed during the app lifetime.     The best thing is probably to test with debug=true or debug=false and see.  But more importantly, with debug=true you will not take advantage of timeouts or other code optimization and that is really a bigger issue than the memory usage.

    What type of debug info does your support team use that would not be available if you have debug=false?   debug.write output for example would still be present…

  63. Tess says:

    Tim,

    Yes, it applies to web services as well.  Web services (asmx) is basically a subset of asp.net

  64. Keith says:

    We've run into this issue in our ASP.net 3.5 code where the machine.congif has the Deployment retail=true and our code managed to get updated in Prod with Debug=true in the web.config.

    However since the machine.config is set it should have been fine, yet it seems this is not working.  Do you know if this is something that works in 3.5?  A look at my memory dumps during an issue led me to the setting and then mass debate occured between systems, architects/devs and our team over how this could not happen..the machine.config settings are there.

    Any experience on this?

    APS.net 3.5.20729.1 (.Net 3.5 SP1) on Windows 2003 64 Bit using 64bit framework.

    Thanks!

  65. Tess says:

    First I thought that debug=true would override this but after looking at this in more detail both in dumps and in documentation I found that retail=true disables the debug=true setting, so if retail=true then debug=true should not be in effect.

    Thanks,

    Tess

  66. Keith says:

    Thanks Tess for the response….we have an issue where the machine.config has retail=true yet when debug=true is set on the web applications our performance goes out the window.  

    If we set it to false (which why wouldn't we on production anyway?) it goes normal.  Our issue has only really been that it slips up there in dpeloyments some times and the last time it got us we put in a critical support ticket with MS who turned around and said you have debugging enabled in production and we see in your dumps that is eating a lot of your resources.

    Which started the debate on retail=true and debug=true.  It seems to me there are a few gotchas still out there and possibly some further digging to what really changes when both these settings are true versus retail=true and debug=false.

  67. If debug=true you will NOT get time-outs no matter what the setting is for retail in machine.config. That is because the ASK.NET Deadlock detection mechanism literally looks in web.config and if denug=true it theoretically runs for an infinite amount of time so that you have more than enough time to attach a debugger.

  68. Scott Yee says:

    Hi Tess,

    Thank you for your posts.  I would not have solved my application's memory issues without this particular post and all the debugging tips throughout your blog.  I've really learned a lot!  

  69. Chien says:

    how do i run a a nifty command in sos.dll ?

  70. Syed says:

    Hi Tess,

    Our application uses one dll called ISDBLayer.dll. This is one of the class library projects in a DLL Solution. When I compile it the solution in Debug mode, and deploy it to production its size is abot 48 kb and the app works fine. Whereas, when I compile it in Release mode (where the size becomes 44 kb), and then deploy it to prod, the application gives an error. This is baffling to me. Any ideas why would such a thing happen just because of a change in the debug/release option.

    Thanks,

    Syed.

  71. NJ says:

    Hi Tess,

    This article is a great read. We have a web application project and use custom http handlers. It has a File import feature to import data from various sources. My question is does this affect custom http handlers? Are the custom http handlers compiled at runtime?

  72. Pranabesh Saha says:

    I am a crazy problem. One of our application (still running under .NET 1.1) runs well at local DEV environment but fails on our PT server. ASP.NET debug=false in PT. Any help ?

    Compilation Error

    Description: An error occurred during the compilation of a resource required to service this request. Please review the following specific error details and modify your source code appropriately.

    Compiler Error Message: CS1595: 'MoreThan.WebInterface.Main.Global' is defined in multiple places; using definition from 'c:WINDOWSMicrosoft.NETFrameworkv1.1.4322Temporary ASP.NET Filesroot1627369fd5eca90eassemblydl23f4ed17e0b566d5_c21ad001MoreThan.WebInterface.Main.Global.asax.cs.DLL'

    Source Error:

    Line 25:    

    Line 26:    

    Line 27:     public class Global_asax : MoreThan.WebInterface.Main.Global {

    Line 28:        

    Line 29:         private static bool __initialized = false;

    Source File: c:WINDOWSMicrosoft.NETFrameworkv1.1.4322Temporary ASP.NET Filesroot1627369fd5eca90ey5v2dlol.0.cs    Line: 27

    Show Detailed Compiler Output:

    Show Complete Compilation Source:

    Version Information: Microsoft .NET Framework Version:1.1.4322.2511; ASP.NET Version:1.1.4322.2515