Finding the right tool for the job
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.
Prev. page
[1]
2
next page 
