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

One of the things you want to avoid when deploying an ASP.NET application into production is to accidentally (or deliberately) leave the <compilation debug=”true”/> switch on within the application’s web.config file.

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

1) The compilation of ASP.NET pages takes longer (since some batch optimizations are disabled)

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

3) Much more memory is used within the application at runtime

4) Scripts and images downloaded from the WebResources.axd handler are not cached

You can see the full article by clicking following links

http://weblogs.asp.net/scottgu/archive/2006/04/11/442448.aspx

In web.config file put the following code to send an email

<healthMonitoring>

<providers>

<add name=“ApplicationMailEventProvider“ type=“System.Web.Management.SimpleMailWebEventProvider,System.Web, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a“ from=noreply@company.com to=jkhatri@company.com” bodyHeader=“Error raised to ApplicationCriticalMailEventProvider“ subjectPrefix=“ERROR:“ buffer=“true“ bufferMode=“Critical Notification“ maxEventLength=“4096“ maxMessagesPerNotification=“1“/> </providers><rules>

<add name=“Application Request Processing Errors“ eventName=“Request Processing Errors“ provider=“ApplicationMailEventProvider“ profile=“Default“/>

<add name=“Application Infrastructure Errors“ eventName=“Infrastructure Errors“ provider=“ApplicationMailEventProvider“ profile=“Critical“/>

</rules>

</healthMonitoring>
</system.web>

]]>