Do not use debug="true" in Production Environment

Hi,

 

This post summarizes why one should not use ‘Debug’ mode in Production environment.

Long back I have already made a post on similar lines. Here are the Details.

 

Few more details are here.

 

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

 

·          The compilation of ASP.NET pages takes longer (Reason - Program is compiled with Full Symbolic Debug Information in Microsoft format).

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

·          Much more memory is used within the application at runtime.

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

 

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.

 

 

Despite of the above shortcomings, there is an advantage attached with Debug mode - More detailed stack trace and line error messages can be provided.

Can we have the taste of both – Compile with Debug Symbols, but deploy in Release mode. Here is the trick below.

 

The good news is that you can do this without having the have the <compilation debug=”true”/> switch enabled in production.  Specifically, you can use either a web deployment project or a web application project to pre-compile the code for your site with debug symbols, and then change the <compilation debug=”true”/> switch to false right before you deploy the application on the server. 

 

The Debug Symbols and METAData in the compiled assemblies will increase the memory footprint of the application.

 

 

Forcing to Remember to not to deploy in Debug Mode -

 

To ensure that no one accidentally deploys an ASP.NET application in production with the <compilation debug=”true”/> switch enabled, one trick you can use with ASP.NET V2.0 is to take advantage of the <deployment> section within your machine.config file.

 

Specifically, by setting this within your machine.config file:

 

<configuration>

    <system.web>

          <deployment retail=”true”/>

    </system.web>

</configuration>

 

This will do below.

 

·          Disable the <compilation debug=”true”/> switch.

·          Disable the ability to output trace output in a page.

·          Turn off the ability to show detailed error messages remotely.

 

 

Setting this switch to true is probably a best practice that any company with formal production servers should follow to ensure that an application always runs with the best possible performance and no security information leakages. 

 

There isn’t a ton of documentation on this switch – but you can learn a little more about it here.

 

Reference: Link

 

Hope this helps,

 

 

 

Thanks & Regards,

Arun Manglick || Senior Tech Lead