To debug an ASP.NET application, first you need to configure debugging. This is a process requires two steps to be taken. First, you must activate the ASP.NET debugger for your current project. To do this, right click on the project in solution explorer, and select Property Pages. In the dialog box, then select Start Options. Look for the Debuggers section in the bottom, and make sure ASP.NET is checked.
The second step is to enable debugging either for your whole application, or just different pages of it. To do so, in the compilation section of the web.config file, set debug=”true”. This causes debugging symbols to be added to your whole page. If you want to debug only some pages, you should set Debug=”true” in the @Page directive of them.
If you have the necessary rights for debugging (the application is running locally under your own user entity, or you’re an administrator) you can debug by now. If it is not the case, you should seek a way to grant yourself these rights. It’s because debugging an application needs more rights than just running it. Debugging can be harmful if not implemented carefully.
If you need to perform remote debugging then check back later, I’ll post how to do it very soon.
When you want to debug a deployed application (which is currently in production usage) you need to attach to the (possibly) remote ASP.NET worker process, and then use Visual Studio to debug it. Note that when you set a breakpoint in the application, any production user will be halted there, so be careful when using one.
When you published your web application to a production server, it is suggested that you set compilation debug to false, because it may slow down your application.
Defining Custom Errors
Error messages are very useful when building any kind of application. We get a detailed log about the problem, its exact place, and sometimes a possible solution. However, our production users may not appreciate these kinds of error messages when they encounter them. Only our potential attackers value them enough, more than us.
So it is generally a good idea to hide detailed error messages, and show some kind of useless, but more user friendly message, e.g. we know about your problem now, working on solving it, etc. ASP.NET lets us implement this behavior easily, with a single set in the web.config, the tag is called customErrors, and lives in system.web.
CustomErrors has two attributes, and can have countless children. The two attributes are defaultRedirect, which is, as its name shows, the default error page of our application, and mode. Mode can have three values: On, which means custom errors are enabled, so users won’t get any detailed error messages, even if you don’t specify a defaultRedirect page. The second value is Off, which means custom errors are disabled in your application, users always get detailed error messages. The third value is RemoteOnly, when you set it, only local (server) clients will get detailed error messages.
If you want to be kind for your users, you can supply them different error pages for different errors, not just a general one. You can do this by adding <error> tags to the <customErrors> tag. An error tag must have two attributes: a statusCode, where you should specify the given HTML status code (errors range from 400 to 599), and a redirect property, with the page name you want to redirect users.
You can also specify custom error pages for different pages in your application, by using the ErrorPage property in the @Page directive. This setting overrides the ones in customErrors.
Please note that the ASP.NET runtime can only redirect requests to error pages if the request is handled by ASP.NET. This means that if a user requests a nonexistent .html file in your application, by default, he/she won’t be redirected to anything. That is because .html files aren’t handled by ASP.NET, but IIS. So if you want to go for sure, you should specify custom error pages in IIS, too.
It is possible to configure ASP.NET to handle .html files, but it’s not the best solution for the problem, because it adds a performance overhead for the runtime.
You can also catch errors, instead of running from them to another page. To catch any unhandled exception in a single page, you should override the page’s onerror event. You can get all available data from the last exception on your page by creating an HttpContext for the current context, then calling its Server.GetLastError method, like the following:
protected override void OnError(EventArgs e)
HttpContext context = HttpContext.Current;
Exception ex = context.Server.GetLastError();
//Now you can do whatever you’d like to with the exception,
//then dispatch the error
You should call Server.ClearError() for the current HttpContext to let the page finish its running.
You can also catch application level errors with the exact same syntax, by defining the Application_Error (object sender, EventArgs e) method in the global.asax file of your web application.