Debugging Strategies

Debugging Visual InterDev applications is a difficult task for a system to handle. When an ASP application is set for debugging, Internet Information Server (IIS) makes the application an out-of-process application, which means that the application runs in a separate memory space. This results in the application running much slower than when the application runs in the IIS process. For this reason, you do not want to turn on debugging for a production application, at least not for long.

Each breakpoint in a page stops and starts the Web server. This also impacts the performance of all other applications running on the site and their state management. Turning on buffering in IIS 4 for applications that are being debugged will speed up those applications.

To properly debug an application, you should have a local Web server on the system on which you are running Visual InterDev or you should use a dedicated development server. You can remotely debug an application, but only one developer can be remotely debugging an application on an IIS system at a time. This means that your development team can actively have only one debug session per development server.

Using a local Web server for debugging alleviates this problem. In that case, you can develop, test, debug, and then deploy the application to the development server when you are ready. This will make the process much easier to manage and much more productive.

NOTE

---

Microsoft highly recommends that you do not use the Active Desktop mode of Internet Explorer 4 when you are debugging.

Setting up an Application for Debugging

You must perform several steps before beginning to debug an application. First set the start page for the application. In Project Explorer, right-click the page you want to start with, and then select Set As Start Page from the context menu.

Before you can debug an application, you must also enable debugging for the application. You can change this setting in Visual InterDev 6 or in IIS 4. To change the Visual InterDev debug settings for a Web project, use the project's Properties dialog box, as shown in Figure 3-2.

Figure 3-2. A project's Properties dialog box, showing the debugging option.

First display the project's Properties dialog box by right-clicking the project in Project Explorer and then selecting Properties from the context menu. On the Launch tab, check the option Automatically Enable ASP Server-side Script Debugging On Launch box under Server Script to enable debugging.

When you enable debugging in Visual InterDev, Visual InterDev lets you debug each time you launch a page within the particular project. This does not affect other applications or other developers. Each time you start the application in debug mode, Visual InterDev will perform the following tasks:

• Set the IIS application to run in its own memory space (that is, out of process).
• Enable the IIS application's debugging options.
• Set up a Microsoft Transaction Server (MTS) package to allow you to attach the debugger to the Web application. The package's identification is set when you first start the debugging session by asking you to provide your name and password.

You can also enable debugging by using the Internet Server Manager subcomponent of IIS. Figure 3-3 shows these debug settings.

Figure 3-3. You can also use the IIS Internet Service Manager to enable debugging.

To display the debug options, select the site in the Internet Service Manager and display its properties. Click the Configuration button, and then click the App Debugging tab. Next check either the Enable ASP Server-side Script Debugging option or the Enable ASP Client-side Script Debugging option. Click OK or Apply to update the settings.

Setting the debug properties with the Internet Service Manager enables this setting for all users of this application. Also, keep in mind that the application will run much slower with these settings turned on.

If you enabled the debug options with Visual InterDev, the first time you launch the application in the debugger after having changed the debugging properties, you might be prompted for a Microsoft Windows NT account and password that has authority to enable debugging on the server.

Debugging ASP Script

Visual InterDev provides tools you can use to debug either client or server code, but each requires a slightly different approach. Let's take a look at debugging server code.

To debug server script from within a Visual InterDev solution:

1. Open the project containing the server script you want to debug.
2. Set the startup page for the application by right-clicking the page you want to run first and choosing Set As Start Page from the context menu.
3. Set a breakpoint in the server script you want to debug.
4. Choose Start on the Debug menu to launch the project.

Visual InterDev now attaches the debugger to the document running on the server. In Internet Explorer, navigate to the .asp file that contains the script you want to debug. When server script execution reaches the line with the breakpoint, the debugger will display the page in the Visual InterDev editor. The current line will be highlighted when the application stops in the editor.

If the .asp file you are debugging is part of your project and you have a working copy, you can fix any errors, save the file, and then click Restart on the Debug menu to restart the debug process.

If debugging is enabled for an application and the server encounters a syntax error or a run-time error in server script, it displays an error message in the requesting browser. Responding Yes to this message will start the debug process. Visual InterDev is launched, and the debugger attaches itself to the script with the error and displays the page in the editor. If the page is part of a project in Visual InterDev, open the project and the page, fix any errors, save the file, and then deploy it to the server. Then refresh the page in Internet Explorer.

If server debugging is not enabled for the application, errors are displayed in the browser as text in the page and you must manually start the debug process in Visual InterDev.

Debugging Global.asa

Debugging Global.asa is a bit more problematic than debugging an ASP Web page. Global.asa is event-based and cannot be started directly (unlike an ASP Web page). The trick is to force a breakpoint in Global.asa's code and start another page that will cause the events in Global.asa to fire.

You can set a breakpoint in Global.asa just as you can in other pages. You can also insert statements in your code that will stop the script language. Either of the statements in Table 3-2 will stop execution and explicitly start the debugger.

Table 3-2. Debug statements for script languages.

Script Language	Stop and Debug Statement
VBScript	Stop
JScript	Debugger

Stepping Through an Application

The Visual InterDev debugger lets you step through the code in your application line by line, checking variables and testing values as you go. This is the process we have used for years in Visual Basic to quickly test applications and get them into production.

The Debug toolbar's Step buttons or the shortcut keys are the easiest way to walk through the code when the debugger stops at a breakpoint or when you start the application. The commands you use to step through your code are described in Table 3-3.

Table 3-3. The debugging step commands.

Debug Menu Command	Button	Action
Step Into (F11)		Moves you to the next script line. If the script calls another procedure, Step Into allows you to step through the lines of the called procedure as well.
Step Over (F10)		Moves you to the next script line. If the script calls another procedure, the procedure is executed but the debugger does not step through the called procedure's individual lines.
Step Out (Shift+F11)		Lets you stop stepping through lines of a procedure before reaching its end.

The Run To Cursor command (Ctrl+F10) or its toolbar button is also useful. When you place the cursor in a page and click Run To Cursor, Visual InterDev will execute the code up to that line. Then you can step through it.

Using Breakpoints

Developers use breakpoints to stop execution of code at a particular point. For instance, if you wish to test a certain line of code, you place a breakpoint on that line. Then, when you run the code in the debugger, the application stops on the line containing the breakpoint and the debugger goes into "break" mode. When the debugger is in break mode, you can inspect variables, execute commands, change the next line to execute, and so forth. Most of your debugging activities will be done in break mode.

You can use a breakpoint (or a statement that will stop execution) to specify a place in a script at which you want to stop and examine the state of a process. You can then step into or step over lines of script individually to find errors. Breakpoints show up as red octagons to the left of a line of script, as shown in Figure 3-4.

Figure 3-4. Breakpoints are indicated by the red octagon in the margin to the left of a line.

It's easy to set a breakpoint:

1. Open the file you're debugging.
2. Place the cursor in the line of script in which you want to set a breakpoint.
3. From the Debug menu, choose Insert Breakpoint.

You can also set a breakpoint by placing the cursor in a line of script and pressing F9 or by clicking in the margin left of the line.

The Breakpoints window displays a list of the breakpoints in your solution, as shown in Figure 3-5. (To open the Breakpoints window, select Breakpoints from the Debug menu or press Ctrl+B.) You can use this window to review the list of breakpoints, clear all the breakpoints in the solution, disable and enable breakpoints, and more.

Figure 3-5. The Breakpoints window allows you to configure each breakpoint in a solution and to review all the breakpoints for that solution.

One of the nice features of the debugger is the ability to set parameters on a breakpoint. One of the parameters you can set is a condition that must be met for that breakpoint to stop the execution of the code. Figure 3-6 shows the properties of a breakpoint with a condition set.

To set a breakpoint's properties, display the Breakpoints window, select the desired breakpoint, and then click Properties. If you are setting a condition, you can set it to break when the condition is true by changing the radio button to the right of the condition.

Breakpoint conditions are extremely useful when you are debugging an application that can have a wide range of values and you only need to test certain values. For instance, you might have a loop in your application that iterates 1000 times. Instead of stepping through each of those iterations, you can use a condition to trigger the breakpoint to stop on the particular iteration you are looking for. You can also use conditions in this manner when you are returning large amounts of data from a database and want to check only certain conditions.

The Breakpoints window is also useful for removing breakpoints. When you have finished debugging your application and are ready to deploy it, you can bring up the Breakpoints window and delete either all or some of the breakpoints.

Figure 3-6. Breakpoint properties allow you to control how the breakpoint is triggered.

Using the Debug Windows

The Immediate window is one of the most used debug windows. It is used to interact with your running Web application. You can enter commands and execute them, display the values of variables, execute functions, and much more. The Immediate window is your central point of contact with the application.

Figure 3-7 shows a simple page that is in break mode. In the example shown, the application has a Select Case statement based upon the sShowThis variable. One of the tricks to testing a Select Case statement is to test it with all of its possible values. This process is usually time-consuming as you run the application several times and try to force the variables through each value change. You might choose to test a Select Case statement by programmatically changing the variable, but doing so still takes time.

The debugger allows us to debug these types of statements dynamically. For instance, let's debug our Select Case statement in Figure 3-7 by changing all of its options. You can see that sShowThis currently has a value of 999 and that the cursor is stopped on the Stop statement, thus putting the application in break mode. (You can tell which line is the current line because the line will be yellow-highlighted and will have a small arrow in the left margin pointing at it.)

Figure 3-7. Once the application is in break mode, you can interact with it line by line.

To continue debugging this page, press F11 to step to the next line. We will continue stepping through the page by pressing F11 until the cursor reaches the End Select statement. At this point, we will have tested the Select Case statement for the 999 condition. We still need to test for a value of 1020 and any values other than 1020 and 999, such as "". To test these other conditions, we need to restart the Select Case statement. To do this, move the cursor to the Select Case line and select Set Next Statement from the Debug menu (Ctrl+Shift+F10). This will move the pointer to that line, and the line will now execute when you press F11 again. So, how do we reset the variable for the new condition? Simply enter a variable definition command into the Immediate window, as shown in Figure 3-8 below.

Once you have reset the variable, you can press F11 to step through the application again, testing another condition. You can iterate through these steps until you have tested every condition of a Select Case or similar statement group.

Other Debug windows can be used with the Immediate window to understand what is happening with your application. Figure 3-8 below shows the Immediate and Watch windows. The Locals window is also active in Figure 3-8 but is hidden behind the Immediate window. You can display hidden windows like this by clicking the tab for the window.

The Watch window is used to display the results of a Watch expression. After a variable or object is placed in the Watch window, the debugger will monitor that variable and continually display its value.

Figure 3-8. The Immediate window can be used to execute almost any script command.

You can drag and drop variables from the code window to either the Immediate window or the Watch window. You can also drag a variable from either window to the other. The Watch window allows you to double-click a variable and edit its value. This is a great feature for interactively debugging your applications.

The Watch window also allows you to monitor objects. If you place an object in the Watch window, you will see a plus (+) sign to the left of the object. Click the plus sign, and the object will expand to display its properties and other objects it contains. In the Value column, you will see the contents of each object's property.

You can display the Watch window by selecting Debug Windows from the View menu and then selecting Watch from the submenu. You can also use the Debug Windows menu item to display the other Debug windows, or you can use their shortcut keys.

Connecting to an Executing Application

The Running Documents window displays the documents that are currently executing. Figure 3-9 shows the Running Documents window with Page1.asp executing with several pages attached to it. Those attached pages are part of the Scripting Library and are providing support for the DTCs used in the page. If you aren't attached to any processes, the Running Documents window will be empty. To view the Running Documents window, select Debug Windows from the View menu, and then select Running Documents from the submenu.

Figure 3-9. The Running Documents window shows the debuggable documents that are currently running on a system.

You can also enter break mode at run time when the application is idle (not processing an event). When you break into a running application, execution stops when the next line of code is executed. This allows you to start a debug session while the application is currently running. This is handy when you are testing and discover an anomaly or just want to observe what is currently happening in the application.

To break into a running application, select Break from the Debug menu.

You can select the Processes command on the Debug menu to use the Processes window to start debugging an active application. Before you can use this technique, you must have enabled debugging on the server for your site. This is handy when you detect an error while the application is running and need to attach the debugger to the application. For this to work, you must enable just-in-time debugging:

1. Select Options from the Tools menu.
2. Select Debugger in the Options dialog box.
3. Under the Script section, check Attach To Programs Running On This Machine.

This allows you to use Visual InterDev to debug any running ASP page that is part of a project that has debugging enabled. Now you can use the Processes window to attach Visual InterDev to the application.

To debug a running script:

1. Select Processes from the Debug menu.
2. In the Processes window, select Active Server Pages.
3. Click Attach.
4. Close the Processes window.
5. Display the Running Documents window (select Debug Windows from the View menu and then select Running Documents from the submenu, or press Ctrl+Alt+R).
6. In the Running Documents window, double-click the script you want to debug, and Visual InterDev will open that page in the source code editor.
7. Set breakpoints, and then choose Restart from the Debug menu or refresh the document in the browser.

Figure 3-10 shows the Processes window after we have attached to the Active Server Pages process. Now we can use the Running Documents window to obtain a list of the running pages and to open the page in the source code editor.

Figure 3-10. The Processes window shows both the active processes and the ones that have been attached.

Debugging Client Code

You can also use Visual InterDev 6 to debug client pages that execute in the browser. This process is similar to debugging server-side ASP code:

1. Open Project Explorer.
2. Right-click the .htm file you wish to start, and select Set As Start Page.
3. Click the Start button on the toolbar, or select Start from the Debug menu.

The script will execute until Internet Explorer reaches the breakpoint. When Internet Explorer reaches the breakpoint, it stops and displays the source script in Source view.

Simultaneously Debugging Server and Client Code

You can debug both server and client code at the same time, as long as all the code is part of one Visual InterDev 6 project. The following is the normal process used when working with an ASP application:

1. Open the project containing the server script you want to debug.
2. Set the Start page for the application by right-clicking the page you wish to run first and choosing Set As Start Page from the context menu.
3. Set breakpoints in the lines of client and server script that you want to debug.
4. Click Start on the toolbar, or choose Start from the Debug menu. The server script will execute and stop at the first breakpoint.

Now you can step through the code line by line. The server code will execute and be sent to the browser. When the browser encounters a breakpoint, it will stop and display the code in Source view.

Of course, you must be careful when debugging client code. Much of the client code that is generated with ASP is dynamic in nature and exists only in the HTML stream to the client. In that case, you must look at the code as a result set only and try to determine what changes must be made to the ASP code to correct any problems.

Just-in-Time Debugging

Visual InterDev allows you to launch the debugger in response to an error in an application. You can do this only if just-in-time debugging is enabled and the application has debugging enabled.

You enable just-in-time debugging via the Options dialog box:

1. Select Options from the Tools menu.
2. In the Options dialog box, choose Debugger.
3. Under the Script section, check Just-In-Time Debugging.

Now when an error occurs or a Stop or Debugger statement appears, a dialog box will ask whether you want to debug the application, as shown in Figure 3-11.

Figure 3-11. This dialog box will appear when a debug statement is encountered or an error occurs.

When you answer Yes to the dialog box shown in Figure 3-11, a new instance of Visual InterDev will be launched and you will be prompted to open a project. If Visual InterDev is already running, a second instance is launched. Open the project containing the file you wish to debug. If the project is already open in another instance of Visual InterDev, you cannot open it again and must create a new solution and project instead. Once you have the page to debug loaded into the editor, you can debug it like any other page.

Debugging Visual Basic Components

You can use Visual InterDev to debug your Visual Basic components directly from an ASP page. You must take a couple of steps to make this work, but the process is pretty simple.

First, the Visual Basic IDE and debugger work similarly to Visual InterDev and its debugger, and the look and feel of each are also similar. Consequently, it's easy for developers to use both tools and to work back and forth between them. The commands are the same, the windows are the same, and even the command keys are almost the same, including our old friend F5 (Run). (One exception is the Step Into command, which is F8 in Visual Basic and F11 in Visual InterDev.) If you use the toolbars, you'll find they also work the same way.

To debug a Visual Basic component, you must execute the component inside the Visual Basic IDE. This is the same technique you use to debug components in Visual Basic 4. To do this, follow these steps:

1. On the machine where the ASP application is running, load the source for the Visual Basic component.
2. Set breakpoints in the component.
3. Execute the component.

These steps will execute the component in the Visual Basic IDE. Executing a component starts the executable and keeps it active. This lets other applications use the component while the component is running in the IDE, with all its Visual Basic resources available. Figure 3-12 demonstrates a component that is loaded in the Visual Basic IDE and executing. Notice that the IDE is in Run mode—the Visual Basic title bar indicates this with the word Run.

Figure 3-12. This component has a breakpoint set and is executing within the Visual Basic IDE.

Now start the debug process with the page that contains the code for executing the component. Figure 3-13 below demonstrates a page that is using the component executing in Figure 3-12.

When you debug the page shown in Figure 3-13 and the line accessing the component executes—that is, objCustInfo.CheckStatus(1)—the Visual Basic IDE will become the current window and you will be debugging the component. Figure 3-14 demonstrates the component during the Visual Basic debug process.

Figure 3-13. This page is using the component running in the Visual Basic IDE.

Figure 3-14. The Visual Basic debugger can be used to interactively debug the component, complete with the data passed to it from the ASP page.