ASP.NET —

Debugging with Visual Studio

The tracing support built into ASP.NET works really well and is a great way to debug your application-especially once it's deployed. However, when you're in development mode, having to plant tracing messages into your page and then run it to see what happened is old school, and sometimes not the most efficient way of debugging. Visual Studio provides excellent debugging support through the environment, and you may use it to watch your code execute and to step through the code one line at a time. In fact, you have access to all of Visual Studio's debugging facilities, even though you're developing Web applications.

Remember, ASP.NET and Visual Studio work in concert to make it feel like you're doing desktop application development, even though it's a Web application. That goes for the debugger, as well. The following exercise will familiarize you with the Visual Studio debugging environment.

Debug an Application

  1. Open the DebugORama Web site. To support debugging, Web.Config needs to include the right settings. You may type it by hand if you wish; however, Visual Studio will insert it for you once you start debugging.

       <system.web>
      <trace enabled="true"/>
      <compilation debug="true"/>
   </system.web>

  2. Open the TraceMe.aspx page and insert breakpoints in Page_Load, AssembleTable, Button1_Click. You may insert breakpoints by highlighting a line in the editor window and pressing the F9 key. You may also select Debug | Toggle Breakpoint from the main menu. Visual Studio will show a big red dot to the left of the breakpoint lines.

    Graphic

  3. Start debugging by pressing the F5 key. You may also debug by selecting Debug | Start Debugging from the main menu. If debugging is not turned on in the Web.Config file, Visual Studio will ask you before it turns on the debugging attribute. Visual Studio will start running the site. When it comes to your breakpoints, Visual Studio will stop execution and highlight the current line in yellow in the window.

    Graphic

  4. In this example, Page_Load is the first breakpoint Visual Studio encounters. At this point, you may start stepping through the code. F10 steps over methods while F11 steps into methods. Alternatively, you may use Debug | Step Over and Debug | Step Into from the main menu.

  5. Hover your mouse cursor over any variables you see. Notice how Visual Studio displays the value of the variable in a ToolTip.

  6. Hit F5 to resume the program. Visual Studio will run until it hits another breakpoint. Run through all the breakpoints.

  7. Next, post back to the server using the button. Notice the breakpoints are hit again. Also notice here that first the Page_Load is hit, and then the Button_Click handler. This highlights the ephemeral nature of a Web page. A new page is being created for each request that comes in.

  8. Finally, try out a couple of the debug windows. You can monitor various aspects of your program by selecting Debug | Window from the main menu and choosing the window. Here's the Locals window, showing those variables within local scope.

    Graphic

  9. The Call Stack window shows how execution finally arrived at this spot. You may trace through and follow the entire program execution up to this point.

    Graphic

    Other notable windows include the Watch window that lets you examine any variable you want. In addition, the Threads window will let you see how many threads are running, what their thread IDs are, and so forth.