Microsoft.NET

……………………………………………….Expertise in .NET Technologies

Visual Studio Debugging

Posted by Ravi Varma Thumati on September 24, 2009

Once you’ve created an application, you can compile and run it by choosing Debug -> Start Debugging from the menu or by clicking the Start Debugging button on the toolbar (which looks like a DVD-style play button). Visual Studio launches your default web browser and requests the page that’s currently selected in the Solution Explorer. This is a handy trick—if you’re in the middle of coding WebPage1.aspx, you’ll see WebPage1.aspx appear in the browser, not the Default.aspx home page.

The first time you launch a web application, Visual Studio will ask you whether you want to configure your web application to allow debugging by adjusting its configuration file. (Figure 4-20 shows the message you’ll see.) Choose “Modify the Web.config file to enable debugging.” and click OK.

Figure Enabling debugging

Debug1 

Visual Studio may also warn you that script debugging is disabled, depending on your browser preferences. Script debugging is a useful tool that works with Visual Studio to help you debug pages that use ASP.NET AJAX. However, there’s no reason to turn script debugging on unless you’re writing client-side JavaScript code in your web pages. (By default, script debugging is disabled in Internet Explorer so that you don’t get error messages when you run someone else’s problematic JavaScript code when visiting a website.) It’s a good idea to choose the “Don’t show this dialog again” to make sure Visual Studio doesn’t repeat the same warning every time you run your web application.

The Visual Studio Web Server

When you run a web application, Visual Studio starts its integrated web server. Behind the scenes, ASP.NET compiles the code for your web application, runs your web page, and then returns the final HTML to the browser. The first time you run a web page, you’ll see a new icon appear in the system tray at the bottom-right corner of the taskbar. This icon is Visual Studio’s test web server, which runs in the background hosting your website. The test server only runs while Visual Studio is running, and it only accepts requests from your computer (so other users can’t connect to it over a network).

When you run a web page, you’ll notice that the URL in the browser includes a port number. For example, if you run a web application in a folder named OnlineBank, you might see a URL like http://localhost:4235/OnlineBank/Default.aspx. This URL indicates that the web server is running on your computer (localhost), so its requests aren’t being sent over the Internet. It also indicates that all requests are being transmitted to port number 4235. That way, the requests won’t conflict with any other applications that might be running on your computer and listening for requests. Every time Visual Studio starts the integrated web server, it randomly chooses an available port.

Visual Studio’s built-in web server also allows you to retrieve a listing of all the files in your website. This means if you create a web application named SampleSite, you can request it in the form http://localhost:port/SampleSite (omitting the page name) to see a list of all the files in your web application folder (see Figure). Then, just click the page you want to test.

Figure Choosing from a list of pages

Debug2 

This trick won’t work if you have a Default.aspx page. If you do, any requests that don’t indicate the page you want are automatically redirected to this page.

Single-Step Debugging

Single-step debugging allows you to test your assumptions about how your code works and see what’s really happening under the hood of your application. It’s incredibly easy to use. Just follow these steps:

  1. Find a location in your code where you want to Pause execution. (You can use any executable line of code but not a variable declaration, comment, or blank line.) Click in the margin next to the line of code, and a red breakpoint will appear (see Figure).
  2. Now start your program as you would ordinarily (by pressing the F5 key or using the Start button on the toolbar). When the program reaches your breakpoint, execution will pause, and you’ll be switched to the Visual Studio code window. The breakpoint statement won’t be executed yet.
  3. At this point, you have several options. You can execute the current line by pressing F11. The following line in your code will be highlighted with a yellow arrow, indicating that this is the next line that will be executed. You can continue like this through your program, running one line at a time by pressing F11 and following the code’s path of execution.
  4. Whenever the code is in break mode, you can hover over variables to see their current contents (see Figure). This allows you to verify that variables contain the values you expect.  
  5. You can also use any of the commands listed in Table 4-2 while in break mode. These commands are available from the context menu by right-clicking the code window or by using the associated hot key.

Figure Setting a breakpoint

Debug3

Figure Viewing variable contents in break mode

Debug4

Commands Available in Break Mode

Command (Hot Key)

Description

Step Into (F11) 

Executes the currently highlighted line and then pauses. If the currently highlighted line calls a method, execution will pause at the first executable line inside the method (which is why this feature is called stepping into). 

Step Over (F10) 

The same as Step Into, except it runs methods as though they are a single line. If you select Step Over while a method call is highlighted, the entire method will be executed. Execution will pause at the next executable statement in the current method.

Step Out (Shift+F11)

Executes all the code in the current procedure and then pauses at the statement that immediately follows the one that called this method or function. In other words, this allows you to step “out” of the current procedure in one large jump.

Continue (F5)

Resumes the program and continues to run it normally, without pausing until another breakpoint is reached.

Run to Cursor

Allows you to run all the code up to a specific line (where your cursor is currently positioned). You can use this technique to skip a time consuming loop.

Set Next Statement

Allows you to change the path of execution of your program while debugging. This command causes your program to mark the current line (where your cursor is positioned) as the current line for execution. When you resume execution, this line will be executed, and the program will continue from that point. Although this technique is convenient for jumping over large loops and simulating certain conditions, it’s easy to cause confusion and runtime errors by using it recklessly.

Show Next Statement

Brings you to the line of code where Visual Studio is currently halted. (This is the line of code that will be executed next when you continue.) This line is marked by a yellow arrow. The Show Next Statement command is useful if you lose your place while editing.

You can switch your program into break mode at any point by clicking the Pause button in the toolbar or selecting Debug -> Break All. This might not stop your code where you expect, however, so you’ll need to rummage around to get your bearings.

When debugging a large website, you might place breakpoints in different places in your code and in multiple web pages. To get an at-a-glance look at all the breakpoints in your web application, choose Debug -> Windows -> Breakpoints. You’ll see a list of all your breakpoints, as shown in Figure.

Figure. The Breakpoints window

debug6

You can jump to the location in code where a breakpoint is placed by double-clicking it in the list. You can also remove a breakpoint (select it and press Delete) or temporarily disable a breakpoint (by removing the check mark next to it). This allows you to keep a breakpoint to use in testing later, without leaving it active.

ADVANCED BREAKPOINTS

Visual Studio allows you to customize breakpoints so they occur only if certain conditions are true. To customize a breakpoint, right-click it in the Breakpoints window, a pop-up menu will appear with several options for making the breakpoint conditional:

  • Click Location to see the exact code file and line where this breakpoint is positioned.
  • Click Condition to set an expression. You can choose to break when this expression is true or when it has changed since the last time the breakpoint was hit.
  • Click Hit Count to create a breakpoint that pauses only after a breakpoint has been hit a certain number of times (for example, at least 20) or a specific multiple of times (for example, every fifth time).
  • Click Filter to restrict the breakpoint to specific processes or threads. (This technique is rarely useful in ASP.NET web page code.)
  • Click When Hit to choose another action that Visual Studio should take when the breakpoint is reached, such as running a macro or printing a debug message. If you choose to take one of these actions, you can also specify whether the breakpoint should force Visual Studio into break mode, or whether your code should continue executing.

Breakpoints are automatically saved with the Visual Studio solution files, although they aren’t used when you compile the application in release mode.

Variable Watches

In some cases, you might want to track the status of a variable without switching into break mode repeatedly. In this case, it’s more useful to use the Autos, Locals, and Watch windows, which allow you to track variables across an entire application. Table below describes these windows.

Variable Watch Windows

Window

Description

Autos

Automatically displays variables that Visual Studio determines are important for the current code statement. For example, this might include variables that are accessed or changed in the previous line.

Locals

Automatically displays all the variables that are in scope in the current method. This offers a quick summary of important variables.

Watch

Displays variables you have added. Watches are saved with your project, so you can continue tracking a variable later. To add a watch, right-click a variable in your code, and select Add Watch; alternatively, double-click the last row in the Watch window, and type in the variable name.

Each row in the Autos, Locals, and Watch windows provides information about the type or class of the variable and its current value. If the variable holds an object instance, you can expand the variable and see its members and properties. For example, in the Locals window you’ll see the variable this (see Figure), which is a reference to the current object inside of which your code is executing (in this case, the web page). If you click the plus (+) sign next to the word this, a full list will appear that describes many page properties (and some system values).

Figure Viewing the current page object in the Locals window

Debug5

If you are missing one of the Watch windows, you can show it manually by selecting it from the Debug -> Windows submenu.

Tip: The Autos, Locals, and Watch windows allow you to change simple variables while your program is in break mode. Just double-click the current value in the Value column, and type in a new value. This allows you to simulate scenarios that are difficult or time-consuming to re-create manually and allows you to test specific error conditions.

The Last Word

You took a quick look at how to use Visual Studio’s rich set of debugging features to get into the brain of your web page code and track down elusive problems.

 

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: