To enable debugging in the project properties

In Visual Studio 2005, use the <Project> Property Pages to set project properties for Web application debugging by doing the following:

• Open the Property Pages by right-clicking the project name in Solution Explorer, and selecting Property Pages.
• Click the Start Options tab.
• Under Debuggers, make sure the ASP.NET box is selected.

To enable debugging in the web.config file

• <compilation> tag. This marks the beginning of the <compilation> section.
• Inside the <compilation> tag, you will create the debug attribute.
• Attributes are case sensitive, so be sure to specify "debug", not "Debug" or "DEBUG."
• Set debug to true.

<configuration>
<system.web>
<compilation defaultLanguage="VB"
debug="true"
numRecompilesBeforeAppRestart="15">
<compilers>
<compiler language="VB;VBScript"
extension=".cls"
type="Microsoft.VisualBasic.VBCodeProvider,system, Version=1.0.5000.0,
Culture=neutral, PublicKeyToken=b77a5c561934e089" />
< compiler language="C#;Csharp"
extension=".cs"
type="Microsoft.CSharp.CSharpCodeProvider,system, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
</compilers>

<assemblies>
<add assembly="ADODB" />
<add assembly="*" />
</assemblies>

<namespaces>
<add namespace="System.Web" />
<add namespace="System.Web.UI" />
<add namespace="System.Web.UI.WebControls" />
<add namespace="System.Web.UI.HtmlControls" />
</namespaces>

</compilation>
</system.web>
</configuration>

Error message "Unable to start debugging on the web server. The server does not support debugging of ASP.NET or ATL Server applications


Get this error if the application mappings for ASP.NET file name extensions (such as .aspx) are not configured correctly in Microsoft Internet Information Services (IIS).

To resolve this go to C:\Windows Directory\Microsoft.Net\Framework\Version and type aspnet_regiis -i to configure the required application mappings correctly

On Trying to Debug an application, by the F5 key I get the error: "Error while trying to run project: Unable to start debugging on the web server. Catastrophic failure"?

This issue occurs if the account that is used to run the ASP.NET Worker process (by default, the ASPNET user account) is not assigned the "Impersonate a client after authentication" user right in the "Local Security Policy" settings. This issue may occur when you install Microsoft Visual Studio .NET after you install Windows 2000 Service Pack 4 (SP4) on the computer. In this situation, the ASPNET account is not assigned the "Impersonate a client after authentication" user right in the "Local Security Policy" settings.To resolve it, please use the method at: To work around the problem, manually assign Impersonate a client after authentication to the IWAM account. To do so, follow these steps:

• Click Start, point to Programs, point to Administrative Tools, and then click Domain Controller Security Policy.
• Click Security Settings.
• Click Local Policies, and then click User Rights Assignment.
• In the right pane, double-click Impersonate a client after authentication.
• In the Security Policy Setting window, click Define these policy settings.
• Click Add, and then click Browse.
• In the Select Users or Groups window, select the IWAM account name, click Add, and then click OK.
• Click OK, and then click OK again.
  

To enforce an update of computer policy, type the following command: secedit /refreshpolicy machine_policy /enforce

The common language runtime is the execution engine for .NET Framework applications.

It provides a number of services, including the following:

• Code management loading and execution
• Application memory isolation
• Verification of type safety
• Conversion of IL to native code
• Access to metadata
• Managing memory for managed objects
• Enforcement of code access security
• Exception handling, including cross-language exceptions
• Interoperation between managed code, COM objects, and pre-existing DLLs like unmanaged code and data
• Automation of object layout
• Support for developer services like profiling, debugging
  

Instead of enabling tracing for individual pages, you can enable it for your entire application. In that case, every page in your application displays trace information. Application tracing is useful when you are developing an application because you can easily enable it and disable it without editing individual pages. When your application is complete, you can turn off tracing for all pages at once.

When you enable tracing for an application, ASP.NET collects trace information for each request to the application, up to the maximum number of requests you specify. The default number of requests is 10. You can view trace information with the trace viewer.

By default, when the trace viewer reaches its request limit, the application stops storing trace requests. However, you can configure application-level tracing to always store the most recent tracing data, discarding the oldest data when the maximum number of requests is reached. For more information.

To enable tracing for an application:

1.Open your Web site's Web.config file. If no Web.config file exists, create a new file in the root folder and copy the following into it:

<?xml version="1.0"?>
<configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0">
<system.web>

</system.web>
</configuration>

2.Add a trace element as a child of the system.web element.

3.In the trace element, set the enabled attribute to true.

4.If you want trace information to appear at the end of the page that it is associated with, set the trace element's pageOutput attribute to true. If you want tracing information to be displayed only in the trace viewer, set the pageOutput attribute to false.

For example, the following application trace configuration collects trace information for up to 40 requests and allows browsers on computers other than the server of origin to display the trace viewer. Trace information is not displayed in individual pages.

<configuration>
<system.web>
<trace enabled="true" pageOutput="false" requestLimit="40" localOnly="false"/>
</system.web>
</configuration>

ASP.NET tracing enables you to view diagnostic information about a single request for an ASP.NET page. Tracing also enables you to write debug statements directly in your code without having to remove them from your application when it is deployed to production servers. You can write variables or structures in a page or simply trace through the execution path of your page or application.

Enabling Tracing

In order for tracing information to be gathered and displayed, you must enable tracing for the page or application. When you enable tracing, diagnostic information and custom tracing messages are appended to the output of the page and sent to the requesting browser. Optionally, you can view this information from a separate trace viewer (Trace.axd) that displays trace information for every page in a given application. Tracing information can help you to clarify errors or undesired results as ASP.NET processes a page request.

Trace statements are processed and displayed only when tracing is enabled. You can control whether tracing is displayed to a page, to the trace viewer, or both.
ASP.NET Tracing and Diagnostics Tracing

ASP.NET tracing writes messages that are displayed on ASP.NET Web pages and the ASP.NET Trace viewer (Trace.axd). In contrast, the Trace class is used to trace write messages to the standard .NET Framework trace output (typically a console window). To make it easier to track how your Web forms interact with business objects and other components, you can integrate ASP.NET tracing output with System.Diagnostics tracing to route all tracing messages to one of these outputs.

Common scenarios that use both ASP.NET tracing and Trace include Web pages that use middle tier business objects to interact with data and business rules, and pages that use enterprise services such as transactions and queues. In these situations the business and enterprise components play key parts in the successful execution of the page, and monitoring their execution flow across the multiple tiers of your application using a single tracing output is desirable.