Debugging support for 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:
- Right click website in Solution Explorer and click Property Pages
- Select Start Options
- 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 |
|---|---|
| 400 | Request not understood |
| 403 | Access denied |
| 404 | Resource not found |
| 408 | Timeout |
| 500 | Internal server error |
| 503 | Server 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 debugger.
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.