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.
End of Article
Prev. page
1
[2]
next page -->
