Many ASP pages contain both client and server script. You can set breakpoints in both client and server script, and as each script executes, it can call the debugger at breakpoints.
If the server is not running on your computer, you use remote debugging to debug the server script in the page. For details about how to set up remote debugging, see Debugging Remotely.
Note It is highly recommended that you do not use Active Desktop™ mode of Microsoft® Internet Explorer 4.0 when you are debugging.
Before you can debug script in ASP pages, you must enable debugging. You can manually enable debugging for your ASP application as described under "Enabling ASP Debugging on the Server" in the Troubleshooting topic. Alternatively, Microsoft® Visual InterDev™ can automatically enable debugging on the server as needed.
Note To debug script in ASP pages, you must be running version 4.0 or later of Microsoft® Internet Information Server (IIS).
To enable script debugging in ASP pages
When these options are set, each time you start a debugging session Visual InterDev checks that the server is configured for debugging. This includes:
When you quit your debugging session, Visual InterDev restores the server debugging settings and out-of-process setting to their previous values.
When you set a breakpoint in client script in a page that contains both server and client script, the debugger tracks the breakpoint even though the position of the breakpoint can change significantly in the file after server script has executed. If server script causes the client script to be written several times into the page, the debugger tracks each breakpoint separately.
You can set breakpoints in server script, client script, or both. If you set breakpoints in both, the debugger will stop at the server script breakpoints first. When you continue to run, the page is sent to the browser, and the debugger will then stop at breakpoints in client script.
To debug pages containing both client and server script
Visual InterDev attempts to attach the debugger to the document running on the server.
When you step out of server script, the page will continue executing until it gets to another server script. When the debugger has finished with server script, the server sends the page to the browser, which displays it.
The debugger stops at the breakpoint and displays the version of the page that is being processed by the browser.
When you are debugging pages that contain both server and client script, remember that server script can potentially insert HTML text and client script into the page. For example, a few lines of server script can dynamically create a large table out of database information, or can write or rearrange client script on the page.
After processing the page, the server removes the server script. As a consequence, the page being processed by the browser can look quite different than it does in the Visual InterDev editor with both server and client script in it. For details about how server script is processed, see Understanding Script Processing.
A special case occurs when you want to debug server script that appears inside a block of client script. In the following, server script first extracts a value from a form and stores it in a variable. Later, inside the block of client script, a block of embedded server script dynamically inserts the value of the variable into a client statement:
<%loginName = Request.Form("loginName")%>
<SCRIPT LANGUAGE="VBScript">
Sub ShowWelcome
txt = "<%=loginName%>"
MsgBox("Welcome, " & txt)
End sub
</SCRIPT>
Note When you write server script inside of client script, the editor does not follow color-coding convention for server script.
If you set a breakpoint on the line with the embedded server script, it is not clear whether you want the debugger to stop on the server script (<%=loginName%>
) or later in the client script (txt =
). Visual InterDev therefore offers you two options:
The default is client breakpoint only. To stop both times, you enable a debugger option.
To enable breakpoints for embedded server script
When you are running the debugger and it breaks on embedded server script, it does not stop directly on the line containing the server script. Instead, it stops on the line of client script or HTML that immediately follows the preceding line of server script. In some cases, this can cause the breakpoint to appear many lines before the embedded server script.
For example, if you set a breakpoint on the embedded server script (<%=loginName%>
) in the following example, the debugger will stop on the <HTML> tag.
<%loginName = Request.Form("loginName")%>
<HTML>
<HEAD>
<SCRIPT LANGUAGE="VBScript">
Sub ShowWelcome
txt = "<%=loginName%>"
MsgBox("Welcome, " & txt)
End sub
</SCRIPT>
</HEAD>
This behavior occurs because when the server is processing the page, it ignores anything that isn't server script. The server doesn't "see" the lines of HTML and client script that precede the embedded server script. To the server, the beginning of the line containing the embedded server script is therefore the one immediately following the preceding line of server script.
To move to the embedded server script, use the debugger's Step Into command.