Systems administrators and Web administrators need to understand that a developers' 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 more access to applications on a server to change server components' features such as Microsoft Transaction Server (MTS). Both Internet Information Server (IIS) 4.0 and Visual InterDev 6.0 provide tools developers can use to debug Web applications, including Active Server Pages (ASP). After you understand how developers might use these debugging tools, you can better incorporate them into your enterprise environment.
The Right Tool for the Job
Debugging ASP applications involves many steps, and you need the right tools
for 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's
code, but this tool works only when you run it from the server hosting the Web
application. You must use remote access software such as PCAnywhere32 to execute
the IIS 4.0 Script Debugger from a remote workstation. Alternatively, you can
use Visual InterDev 6.0's Script Debugger to debug ASP applications remotely.
Many developers prefer to use the Visual InterDev 6.0 Script Debugger because
it'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 both
the server and client options to allow complete debugging of the application.
Activating server- and client-side debugging creates overhead on the IIS server because these options apply to all pages associated with the application you want to debug. This overhead can slow a busy Web site's response time. For this reason, I recommend that you completely debug your application on a test or development server. After the application is clean, you can publish it on a production server. These precautions don't remove the need to occasionally test a production application to determine why a particular problem is occurring on the production server.
With Visual InterDev 6.0 Microsoft addressed the problem of slowing the production server during debugging. The debugging tools in Visual InterDev 6.0 let developers automatically configure the debugging options as needed. So for example, when a developer turns on the debugging options for a particular Visual InterDev 6.0 project (i.e., Web application), the software saves those options and uses them when that developer executes the project within Visual InterDev 6.0. If another developer or user accesses the project, Visual InterDev 6.0 doesn't set the debugging options. This configuration lets you turn off the debugging options on the server and lets the developer automatically set these options as needed.
To set the debugging options in Visual InterDev 6.0, go to the Project Explorer, right-click the project, and select Properties to display the project's Launch properties, as Screen 2, page 178, shows. Select the Launch tab to display the Launch dialog box, select the Automatically enable ASP server-side script debugging on launch check box, and click OK. Visual InterDev 6.0 will automatically set the debugging property when you execute the application 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 by
selecting the Microsoft Script Debugger option during the IIS 4.0 setup. You can
use the Script Debugger to debug ASP, HTML, and Windows Scripting Host (WSH)
files.
You can activate the Script Debugger to debug an application in several ways. 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 ASP application. 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 and attempting to open default.asp. The IIS 4.0 Script Debugger is running in the front of Screen 3 with the default.asp page in its open window. An arrow in the left margin of the scripting window identifies which line of application code the Script Debugger is debugging. To open default.asp in the Script Debugger, I selected it from the Running Documents window. The Running Documents window shows you all the running applications and associated pages that the Script Debugger can work with. I selected Microsoft Active Server Pages and drilled down until I located my application (i.e., IE4SemSource). I continued searching until I found the specific page I wanted to debug, and I double-clicked the page to open it in the Script Debugger.
After you open a page in the IIS 4.0 Script Debugger, you can begin to work with it. You can set a breakpoint on any line where you want the page to automatically stop during execution. For example, imagine you want to set a breakpoint on the following line: <% if StartPageProcessing() Then Response.End() %>. To set the breakpoint, you click in the line where you want the breakpoint and press F9. This series of steps will highlight the line and place a 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 in several ways. For example, you can execute one line of the code at a time by clicking one of the following buttons:
- Step Into--executes the next line and if that line calls a subprocedure, steps into that procedures code (F8)
- Step Over--executes the next line and if that line calls a procedure, executes the entire procedure's code without stepping into it (Shift+F8)
- Step Out--exits a stepped-into procedure (Ctrl+Shift+F8)
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 and inspect variables (while the page is executing) that the ASP code sets based on a 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 of the logic for complex code in an application. Without this feature, you'd need to execute the application in the same manner as a user and test every possible scenario.
Screen 5 shows the IIS 4.0 Script Debugger with the Command Window open and the page stopped on the Select Case line. In this example, I need to test the Select 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 the Select Case line to stop the IIS 4.0 Script Debugger on that line. Next, I opened the Command Window. The first line in the Command Window displays the contents of Session ("Department"). The question mark (?) is shorthand for Print. The second line in the Command Window is for changing the contents of Session("Department"). In Screen 5, I changed the contents to MNF. Using the Command Window, I can quickly test the various options (i.e., logic) in the application and make changes accordingly.
| Visual InterDev 6.0 includes complete round-trip debugging features that go well beyond those of the IIS 4.0 Script Debugger. |
The IIS 4.0 Script Debugger opens files as read only. When you work on an application, you must consider this limitation and plan accordingly. If you use Visual InterDev 1.0, you can open your project in that application and use the Script Debugger to test the application. Then you can make changes in Visual InterDev 1.0 and test the application again.
If you enable IIS 4.0's debugging feature for an application and you are running the application, the IIS 4.0 Script Debugger will try to open the page containing the error when it encounters a bug. This automatic behavior is useful when 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 as
the IIS 4.0 Script Debugger with the added benefit of having the VB development
environment. By the time this article is published, the beta version of Visual
InterDev 6.0 should be available. I suggest that developers get their hands on
this upgrade quickly.
Visual InterDev 6.0 includes complete round-trip (i.e., server- and client-side) debugging features that go well beyond those of the IIS 4.0 Script Debugger. For starters, to debug a page in Visual InterDev 6.0, you must set the startup page that you want to execute first by right-clicking the page in Project Explorer and selecting Set as Start Page from the context menu. This page doesn't need to be the same page that contains the breakpoints; this page is simply the starting point for your application.
Next, you start the application by clicking Start on the toolbar, selecting Start from the Debug menu, or pressing F5. Starting the application will open the page you selected as the start page in the default Web browser and then open that page in Visual InterDev 6.0 in the debugging configuration. After you see the page open in the Web browser, you can interact with it as you ordinarily would.
You can set breakpoints, step into procedures, and perform other tasks using Visual InterDev 6.0 Script Debugger just as you do with IIS 4.0 Script Debugger. In addition to performing these tasks, you can use new features in Visual InterDev 6.0. So to set a breakpoint, you can press F9 or click the left margin of the editor on the line in which you want to set the breakpoint. You can also set the current line to any line in the current scope so that you can test parts of an application without re-executing other code. For example, to test the Select Case statement from my previous example, you test the Select Case statement with one value, change the value, change the current line back to the Select Case statement, and complete the test without moving out of that block of code. This debugging feature improves a developer's ability to quickly work through the code in an application, find problems, fix them, and complete the process.
Visual InterDev 6.0 also lets you work on your ASP code during the debugging 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 in place.
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 ASP
applications. The IIS 4.0 Script Debugger enhances all those features by letting
you gracefully debug your applications.
Visual InterDev 6.0 Script Debugger provides new features for debugging ASP applications. In addition to these features, Visual InterDev 6.0 provides a new object model, new tools, a new interface to give developers an indispensable resource for building applications. Visual InterDev 6.0 is the first true Microsoft rapid application development (RAD) tool for building Web applications.
Still, some system administrators might be asking, "What do these tools require on the server?" Remote debugging with Visual InterDev 6.0 requires a user account with administrator privileges on the server. Also, you can conduct only one remote debugging session at a time on each server. These requirements emphasize the importance of having development servers that developers can use to create and test applications, and limiting developer privileges on production servers.
