1. Computing

Learn ASP.NET 2.0 - Debugging

Part 7 of an About Visual Basic Tutorial

By

Updated April 27, 2008

This is a free tutorial to help beginning programmers get up to speed building their own web pages using ASP.NET 2.0. In this tutorial, I concentrate on using free software tools from Microsoft including Visual Web Developer 2008 Express and SQL Server 2005 Express. To get the most from this tutorial, you might want to start at the beginning:

Part 1 - A "From the Ground Up" Tutorial - Programming for the networked world.

Reviewing the problem

An application starts at the browser when a particular file is requested from a server. The server could be IIS, the ASP.NET web development server, or something entirely different like the Mono ASP.NET server. An ASP.NET application will execute code at the server and read several different files including:

  • web.config
    We have used this XML based file in previous lessons to control the way our application works.
  • Directives in the .aspx file
    Directives start with the characters "<%@". The most common one is the Page directive but there are currently 12 different directives such as Control and Implements.
  • Database files
    In a SQL server environment, this includes both the .mdf database and the .LDF log file. More code can exist in database stored procedures.

And of course ...

  • .aspx and .vb partial class files that may or may not be compiled.

Once the page is returned to the browser, more code can be executed including scripts executed by the browser. Execution at the browser is fundamentally a "Windows" process and is outside the VB.NET environment.

The point is that there is a lot that can "go wrong" in the process. I'm amazed that it works at all.

So ... lets start at the beginning and see how to configure basic debugging at the source code level on the server. (Program tracing was introduced in parts 4 and 5 of this tutorial.)

The default for a new web site using Visual Web Developer (VWD from now on) is that debugging is not enabled in the web.config file. This is shown in the screenshot below.

--------
Click Here to display the illustration
Click the Back button on your browser to return
--------

You should always change compilation debug="true" back to "false" before deploying your website to a production server because debug="true" loads debugging symbols into your website and slows it down.

VWD includes the tools that you might have used in Visual Studio for debugging. Breakpoints can be set or removed by either using the Debug menu or clicking in the far left column. A breakpoint suspends the program while it's running and lets you check the value of variables or step through the next sequence of instructions one at a time.

--------
Click Here to display the illustration
Click the Back button on your browser to return
--------

The value of variables can be checked using the Locals, Watch, or Immediate windows under the Debug menu.

The Call Stack window can be both useful and confusing. The term "stack" is the calls that have been made to get to where the program is currently suspended. (You can't view the Call Stack window unless you have suspended execution using breakpoint.) Here's the Call Stack window for the breakpoint shown earlier.

--------
Click Here to display the illustration
Click the Back button on your browser to return
--------

To better understand the fields that the display options provide (right-click to see the context menu), try selecting them one at a time to see what they show.

If you're not debugging your VB.NET program, and you're using IE, the next thing you will probably see is shown below:

--------
Click Here to display the illustration
Click the Back button on your browser to return
--------

To illustrate this, consider the simple script added to the <head> section of a website:

   <script type="text/javascript" language="JavaScript">
<!--
alert("Welcome to the Ask AVB Web Site!");
alert(this is an error);
//-->
   </script>

Even though this is an obvious error, running the page simply ignores the entire script until the setting in IE is changed. When the checkbox is cleared and website is started again in debugging mode, a popup shows you that ...

--------
Click Here to display the illustration
Click the Back button on your browser to return
--------

In a perfect world, you would be able to pop open a great debugging environment to figure out the bug. Some of you may be able to do exactly that with Visual Studio or the Microsoft Script Editor (MSE7.EXE). I haven't been able to get it to work on my configuration (IE7, Vista Business SP1, Visual Web Developer 2008). And, at the present time, there are not a lot of really good (and also simple) alternatives. A lot of people report that FireFox has a much better debugging environment and if a client JavaScript error is your problem, that might be a good option for you.

I can report that IE8, (currently - May 2008 - in beta) will include a a built-in lightweight debugger that will let you set breakpoints and step through client-side script without leaving Internet Explorer. It must be the competition from FireFox!

  1. About.com
  2. Computing
  3. Visual Basic
  4. Learn VB.NET
  5. Learn ASP.NET
  6. Learn ASP.NET 2.0 - Debugging

©2014 About.com. All rights reserved.