The distributed nature of Web applications requires that developers be able to seamlessly debug application logic across both the client and the server, and attach to and debug processes running on remote servers. With Visual InterDev 6.0, developers can now set breakpoints on both client- and server-side script, step through code, add "watch" variables, investigate the call stack, and debug remote Web servers.

Developers can choose from one of three debugging configurations in Visual InterDev. Each configuration enables a subset of Visual InterDev debugging capabilities. Of the several potential pitfalls to successfully debugging Visual InterDev applications, most are related to setup failures and incorrect security permissions. This article describes how to set up and use each configuration.

Visual InterDev 6.0 permits developers to debug client scripts running in HTML or Active Server Pages (ASP) pages against their local workstation using a local copy of Personal Web Server in Microsoft Windows® 95 or Windows® 98. This configuration does not support debugging of server script in ASP pages.

Typically, individual developers use Local mode in Visual InterDev 6.0 to build, test, and debug portions of the application in isolation from the rest of the team. In this case, they run a local copy of Microsoft Internet Information Server (IIS) on their Windows NT® development machine to debug their Web pages before checking them into the master Web project. This is the recommended debugging configuration in Visual InterDev 6.0.

Developers can also attach to and debug server scripts running in ASP pages on a remote IIS. This is a powerful feature that permits a developer to issue debugging commands across the network; however, it is limited in that only one user can use Remote Debugging on a server at a time.

The Debug menu contains commands that enable you to manage how scripts are executed while you are debugging.

Debug Menu Commands

Run

Causes execution to resume from the current statement.

Stop Debugging

Runs the current script to the end without stopping at any breakpoints.

Break at Next Statement

Causes execution to stop at the next scripting statement in the currently attached document. You typically choose this command, and then refresh the document in the browser.

Step Into

Executes one statement at a time from the current execution point. If the statement is a call to a procedure, the next statement displayed is the first statement in the procedure. If there is no current execution point, the Step Into command might appear to do nothing until you perform an action that triggers a script, such as clicking a button.

Step Over

Executes one statement from the current execution point. However, if the current statement contains a call to a procedure, the Step Over command executes the procedure as a unit, and then steps to the next statement in the current procedure. Therefore, the next statement displayed is the next statement in the current procedure even if the current statement is a call to another procedure.

Step Out

Executes the remaining lines of the current procedure. The next statement displayed is the statement following the procedure call. All of the script is executed between the current and the final execution points of the procedure.

Toggle Breakpoint

Sets or removes a breakpoint at the current line. In client scripts, you cannot set a breakpoint on lines containing non-executable script such as comments, declaration statements, or blank lines.

Clear All Breakpoints

Removes all breakpoints in your script. Your script can still interrupt execution, however, if you have embedded Stop (VBScript) or debugger (JScript or Java) statements, or if a runtime error occurs in your script.

Note: Some of the content on this page was reproduced from MSDN library for reference