Debugging ASP Applications with IIS and Visual InterDev

Finding the right tool for the job

Systems administrators and Web administrators need to understand that adevelopers' tools and a developers' ability to access servers play an important role in creating and testing Web applications. As development tools mature, developers will require greater access to specific parts of a server or moreaccess to applications on a server to change server components' features such asMicrosoft Transaction Server (MTS). Both Internet Information Server (IIS) 4.0and Visual InterDev 6.0 provide tools developers can use to debug Webapplications, including Active Server Pages (ASP). After you understand howdevelopers might use these debugging tools, you can better incorporate them intoyour enterprise environment.

The Right Tool for the Job
Debugging ASP applications involves many steps, and you need the right toolsfor the job. Both IIS 4.0 and Visual InterDev 6.0 provide the necessary tools.You can use the IIS 4.0 Script Debugger to step through an ASP application'scode, but this tool works only when you run it from the server hosting the Webapplication. You must use remote access software such as PCAnywhere32 to executethe IIS 4.0 Script Debugger from a remote workstation. Alternatively, you canuse Visual InterDev 6.0's Script Debugger to debug ASP applications remotely.Many developers prefer to use the Visual InterDev 6.0 Script Debugger becauseit's more powerful than the IIS 4.0 Script Debugger.

Optimizing Debugging to Minimize Overhead
The new debugging features in IIS 4.0 and Visual InterDev 6.0 depend on IIS server settings in the Metabase, a configuration store for IIS similar to the Windows NT Registry. Screen 1, page 178, shows the Application Configuration properties in the Internet Service Manager (ISM). In Screen 1, I selected boththe server and client options to allow complete debugging of the application.

Activating server- and client-side debugging creates overhead on the IISserver because these options apply to all pages associated with the applicationyou want to debug. This overhead can slow a busy Web site's response time. Forthis reason, I recommend that you completely debug your application on a test ordevelopment server. After the application is clean, you can publish it on aproduction server. These precautions don't remove the need to occasionally testa production application to determine why a particular problem is occurring onthe production server.

With Visual InterDev 6.0 Microsoft addressed the problem of slowing theproduction server during debugging. The debugging tools in Visual InterDev 6.0let developers automatically configure the debugging options as needed. So forexample, when a developer turns on the debugging options for a particular VisualInterDev 6.0 project (i.e., Web application), the software saves those optionsand uses them when that developer executes the project within Visual InterDev6.0. If another developer or user accesses the project, Visual InterDev 6.0doesn't set the debugging options. This configuration lets you turn off thedebugging options on the server and lets the developer automatically set theseoptions as needed.

To set the debugging options in Visual InterDev 6.0, go to the ProjectExplorer, right-click the project, and select Properties to display theproject's Launch properties, as Screen 2, page 178, shows. Select the Launch tabto display the Launch dialog box, select the Automatically enable ASPserver-side script debugging on launch check box, and click OK. VisualInterDev 6.0 will automatically set the debugging property when you execute theapplication in Visual InterDev 6.0.

Using the IIS 4.0 Script Debugger
Before you can use the IIS 4.0 Script Debugger, you must install it byselecting the Microsoft Script Debugger option during the IIS 4.0 setup. You canuse the Script Debugger to debug ASP, HTML, and Windows Scripting Host (WSH)files.

You can activate the Script Debugger to debug an application in severalways. For example, if you're working with an ASP application, you can directly activate the Script Debugger by placing the appropriate statement in your code. To stop your application code and activate the Script Debugger in Visual Basic Script (VBScript), you use the stop command. Likewise, you use the debugger command to activate the Script Debugger in JavaScript. When your application code encounters either of these two statements, it will stop the application and activate the Script Debugger.

You can also use the IIS 4.0 Script Debugger to debug a running ASPapplication. To start the Script Debugger in this manner, open the application's start page in your Web browser to start the application. Next, start the Script Debugger from the IIS server's Start menu. Now you can associate the Script Debugger to your application.

Screen 3 shows the Script Debugger running. In this screen, I am running Visual InterDev 1.0 behind the other applications and using it to work on the IE4SemSource Web application. Internet Explorer (IE) 4.0 is also running andattempting to open default.asp. The IIS 4.0 Script Debugger is running in thefront of Screen 3 with the default.asp page in its open window. An arrow in theleft margin of the scripting window identifies which line of application codethe Script Debugger is debugging. To open default.asp in the Script Debugger, Iselected it from the Running Documents window. The Running Documents windowshows you all the running applications and associated pages that the ScriptDebugger can work with. I selected Microsoft Active Server Pages and drilleddown until I located my application (i.e., IE4SemSource). I continued searchinguntil I found the specific page I wanted to debug, and I double-clicked the pageto open it in the Script Debugger.

After you open a page in the IIS 4.0 Script Debugger, you can begin to workwith it. You can set a breakpoint on any line where you want the page toautomatically stop during execution. For example, imagine you want to set abreakpoint on the following line: <% if StartPageProcessing() Then Response.End() %>. To set the breakpoint, you click in the line where you want thebreakpoint and press F9. This series of steps will highlight the line and placea red dot indicator in the left margin next to that line, as Screen 4 shows.Now, if you refresh the page, the page will stop on that line during execution.

After you set a breakpoint for a page, you can interact with the page inseveral ways. For example, you can execute one line of the code at a time byclicking one of the following buttons:

After you become familiar with the Script Debugger, you can quickly walk through the code in an application using these step commands. The function keys for the step commands are handy because they let you walk through the code with the touch of a key. I use the Step Over command most often because it lets me work at one level in a page. In addition, the Step Over command handles procedures such as black boxes so I don't need to open the black box unless I suspect it's causing a problem.

The Script Debugger also provides the Command Window for troubleshooting your applications. You open the Command Window from the toolbar or by selecting Command Window from the View menu. You can use the Command Window to display andinspect variables (while the page is executing) that the ASP code sets based ona user's input. The Command Window also lets you test an application's logic.For example, you can use the Command Window to step through the various parts ofthe logic for complex code in an application. Without this feature, you'd needto execute the application in the same manner as a user and test every possiblescenario.

Screen 5 shows the IIS 4.0 Script Debugger with the Command Window open andthe page stopped on the Select Case line. In this example, I need to test theSelect statement for all possible contents of Session("Department").This particular page tests this variable for four possible values: IT, MNF, HR,and ENG. For these values, the application executes the appropriate statement.If the value is not one of these strings, then the case else statement executes.

To test the application code in my example, I placed a breakpoint on theSelect Case line to stop the IIS 4.0 Script Debugger on that line. Next, Iopened the Command Window. The first line in the Command Window displays thecontents of Session ("Department"). The question mark (?) is shorthandfor Print. The second line in the Command Window is for changing the contents of Session("Department"). In Screen 5, I changed the contents toMNF. Using the Command Window, I can quickly test the various options (i.e.,logic) in the application and make changes accordingly.

The IIS 4.0 Script Debugger opens files as read only. When you work on anapplication, you must consider this limitation and plan accordingly. If you useVisual InterDev 1.0, you can open your project in that application and use theScript Debugger to test the application. Then you can make changes in VisualInterDev 1.0 and test the application again.

If you enable IIS 4.0's debugging feature for an application and you arerunning the application, the IIS 4.0 Script Debugger will try to open the pagecontaining the error when it encounters a bug. This automatic behavior is usefulwhen you're developing an application and you need help identifying errors.

Using the Visual InterDev 6.0 Debugger
The Visual InterDev 6.0 debugging tools are based on the same methodology asthe IIS 4.0 Script Debugger with the added benefit of having the VB developmentenvironment. By the time this article is published, the beta version of VisualInterDev 6.0 should be available. I suggest that developers get their hands onthis upgrade quickly.

Visual InterDev 6.0 includes complete round-trip (i.e., server- andclient-side) debugging features that go well beyond those of the IIS 4.0 ScriptDebugger. For starters, to debug a page in Visual InterDev 6.0, you must set thestartup page that you want to execute first by right-clicking the page inProject Explorer and selecting Set as Start Page from the context menu. Thispage doesn't need to be the same page that contains the breakpoints; this pageis simply the starting point for your application.

Next, you start the application by clicking Start on the toolbar, selectingStart from the Debug menu, or pressing F5. Starting the application will openthe page you selected as the start page in the default Web browser and then openthat page in Visual InterDev 6.0 in the debugging configuration. After you seethe page open in the Web browser, you can interact with it as you ordinarilywould.

You can set breakpoints, step into procedures, and perform other tasksusing Visual InterDev 6.0 Script Debugger just as you do with IIS 4.0 ScriptDebugger. In addition to performing these tasks, you can use new features inVisual InterDev 6.0. So to set a breakpoint, you can press F9 or click the leftmargin of the editor on the line in which you want to set the breakpoint. Youcan also set the current line to any line in the current scope so that you cantest parts of an application without re-executing other code. For example, totest the Select Case statement from my previous example, you test the SelectCase statement with one value, change the value, change the current line back tothe Select Case statement, and complete the test without moving out of thatblock of code. This debugging feature improves a developer's ability to quicklywork through the code in an application, find problems, fix them, and completethe process.

Visual InterDev 6.0 also lets you work on your ASP code during thedebugging process. When you open an application and debug it as I've discussed,you can edit the code, save it, and restart the application with the changes inplace.

The Visual InterDev 6.0 Script Debugger provides several debugging windows. The Immediate window works like the IIS 4.0 Script Debugger's Command Window. The Watch window automatically shows the values of variables that are in the application and the values of variables that you have placed in this window. This window provides you with a continually updated view of the application. The Locals window automatically shows the value of all variables in the current scope, including the server objects. The Running Documents window shows all pages (documents) that are available for debugging. The Call Stack window shows the active procedures and lets you quickly move from one procedure to another.

Establishing Your Debugging Environment
IIS 4.0 provides you with many tools and features that simplify running ASPapplications. The IIS 4.0 Script Debugger enhances all those features by lettingyou gracefully debug your applications.

Visual InterDev 6.0 Script Debugger provides new features for debugging ASPapplications. In addition to these features, Visual InterDev 6.0 provides a newobject model, new tools, a new interface to give developers an indispensableresource for building applications. Visual InterDev 6.0 is the first trueMicrosoft rapid application development (RAD) tool for building Webapplications.

Still, some system administrators might be asking, "What do thesetools require on the server?" Remote debugging with Visual InterDev 6.0requires a user account with administrator privileges on the server. Also, youcan conduct only one remote debugging session at a time on each server. Theserequirements emphasize the importance of having development servers thatdevelopers can use to create and test applications, and limiting developerprivileges on production servers.