Debugging ASP.NET websites

More complex than with WinForms as web requests are short lived, client and server typically on different machines, client capabilities vary greatly, state information distributed between database, web server, cache, session, cookie, etc.

Activating ASP.NET Debugger

Configure ASP.NET debugger settings in project property pages:

  1. Right click website in Solution Explorer and click Property Pages
  2. Select Start Options
  3. In Debuggers section choose what areas to be debugged - ASP.NET, native code, SQL, Silverlight

Configuring Debugging

Enable debugging for either entire site, or on page-by-page basis.

Although debugging may be enabled within Visual Studio, individual sites can disable it for security reasons.

By default websites are created with debugging disabled.

Enabling adds debug symbols to compiled code - slows down execution and sends additional information to client (security risk).

Only turn on debugging in development environments.

Enable debugging via web.config

<system.web>

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

</system.web>

Might not want to enable for entire site, can enable on page basis via @ Page directive:

<%@ Page Debug="true" ... %>

When enabled Visual Studio automatically attaches to ASP.NET web server process (unless developing remotely). Can then set breakpoints, step through code, examine variables, etc.

Custom Error Pages

Likely don't want users to see default ASP.NET error pages, instead want to show page telling them to contact customer support.

Custom Site-Level Error Page

Configured via <customErrors> element in web.config which has two attributes:

  • mode - can be on (turn customer errors on), off, or RemoteOnly - only show customer errors to remote clients, clients running on same machine as server see normal error pages.
  • defaultRedirect - path to default error page

On redirection server passed path of page causing error as part of query string

Error specific error pages

Can define error pages for various HTTP status codes using <error> element.

Allows more specific information to be provided to users.

<system.web>

    <customErrors defaultRedirect="SiteError.aspx" mode="RemoteOnly">

        <error statusCode="403" redirect="RestrictedAccess.aspx" />

    </customErrors>

</system.web>

Errors between 400 and 499 represent request errors.

Those between 500 and 599 are for server errors.

Code Description
400Request not understood
403Access denied
404Resource not found
408Timeout
500Internal server error
503Server capacity exceeded

 

Debugging Remotely

Normally debug locally on development machine. May be occasions when this is not possible, e.g. problem only manifests itself on remote server.

Enabling Remote Debugging made easier by Visual studio Remote Debugging Monitor (msvsmon.exe).

Run this tool on server to be debugged, typically one instance for each debugee.

Tool first determines if firewall will allow remote debugging - prompts user to open ports if necessary.

Once running the UI displays debugging events.

Can use to set debugging security options on server - via Tools | Options. Each instance of the Debugging Monitor will have a server name. Can restrict access to specific users via Permissions dialogue.

On client open Visual Studio solution containing code to be debugged.

Select Debug | Attach To Process

Set Qualifier to server name defined for Remote Debugging Monitor.

Will then see list of processes running on that server - select appropriate one to attach to.

Debugging Client-Side Script

Can debug client script running in browser.

Need to enable script debugging support in browser - in Internet Explorer select Tools | Internet Options, on the Advanced tab clear Disable Script Debugging.

Set breakpoint in client script via Visual Studio.

Alternatively can manually attach to code running in browser.

Download