Configuring IIS for Visual InterDev 6.0 ASP Debugging

\[Editor's Note: Each month, this column discusses various aspects of the advanced administration of e-business sites. This month's column examines the setup and configuration of IIS servers for developer debugging.\]

We recently walked into a light-hearted discussion among our fellow network and infrastructure folks. They were competing with one another who was expert in more obscure technologies. "I know Nortel Networks ATM switches," one said. "I've mastered Microsoft Application Center 2000 Request Forwarding," said another. "We figured out how to get debugging to work with Microsoft Visual InterDev on IIS." They all burst out laughing. Why? Because historically, setting up Visual InterDev debugging on IIS has been difficult, and the technology is broken in many spots. In fact, many service packs for Windows NT 4.0 have dedicated fixes for Microsoft Visual Studio (VS) debugging. (Visual InterDev, Microsoft's Web page development tool, ships with VS.)

Setting up an IIS server for debugging is a lot easier now because of better documentation and service pack hotfixes. If you want to be the hero of the developers in your shop, follow the simple steps we provide here on a test box. Then, you can let your developers know that you're available as a resource to help them set up Visual InterDev 6.0 debugging on their local development server environments.

Setting Up Visual InterDev for Remote Debugging
Before we show you how to set up Visual InterDev, note that you should never configure a production Internet server for VS debugging because doing so adds more points of entry for an attacker. You should complete this process only on development servers that are behind your firewall.

To configure IIS for Visual InterDev debugging, you need VS 6.0 Enterprise Edition and administrative privileges for the machine on which IIS is running. In this example, you set up IIS for local debugging on a developer machine (the same computer on which you've installed VS—not an IIS server that runs remotely on a different machine).

The easiest way to correctly set up Visual InterDev and IIS is to go through the steps required for remote debugging. Visual InterDev Help is an excellent resource, so have the Help file ready, or print the remote debugging setup section before you start. Alternatively, you can find the same document on the Microsoft Developer Network (MSDN) Web site. To set up remote-machine debugging, follow these steps:

1. On the server machine, start the VS setup program.
2. Under Add/Remove Options, select Server Applications and Tools.
3. Select Launch BackOffice Installation Wizard, then click Install, as Figure 1 shows.
4. When the BackOffice Business Solutions Wizard appears, select the Custom option, then click Next.
5. Click Next until you see a list of BackOffice programs to install. Clear the check boxes for all the programs except Remote Machine Debugging, FrontPage Server Extensions, and Visual InterDev Server, as Figure 2 shows.

You must reboot your server when you've completed these steps. After you've rebooted, you must install the latest VS service pack, which is currently Service Pack 5 (SP5). You can download the service pack from http://msdn.microsoft.com/vstudio/sp/vs6sp5. Reboot again after you've installed the service pack.

Creating a Web Application to Debug
Now that you've set up Visual InterDev, you can use it to create a project that you can use for debugging. Follow these steps:

1. Start Visual InterDev to call the New Project Wizard. Under Visual InterDev Projects, choose New Web Project, as Figure 3, page 8, shows.
2. Name the project (or use the default—Project1), then click Open to start the Web Project Wizard.
3. On the Specify a server and mode page, which Figure 4, page 8, shows, select the IIS server on your local machine (e.g., ClydeRs) from the What server do you want to use drop-down list. Select the Master mode option, and click next.
4. On the Specify your Web page, select the Create a new Web application option and use the project name you designated in Step 2.
5. Click Next, then click Finish. Visual InterDev creates a virtual directory on your IIS server. Now you have two copies of your project, which Visual InterDev saved in directories with similar names: \projectname\projectname_local and \inetpub\wwwroot\projectname.
6. Modify the virtual directory Visual InterDev just created by exiting Visual InterDev and starting Internet Services Manager (ISM—for IIS 5.0) or opening the Microsoft Management Console (MMC) Internet Information Server snap-in (for IIS 4.0).
7. From ISM or the Internet Information Server snap-in, right-click your virtual directory's name, then select Properties.
8. On the Directory tab, click Configuration.
9. Click the App Debugging tab, which Figure 5 shows, and select the Enable ASP server-side script debugging and Enable ASP client-side script debugging check boxes. Click OK twice.
10. If you want to modify security to No Anonymous Access (or another security model) on this virtual directory, right-click your virtual directory's name, select Properties, and click the Directory Security Tab. Under Anonymous access and authentication control, click Edit. Under Authentication Methods, clear the Anonymous Access check box.
11. ISM or the Internet Information Server snap-in will now find and fix any discrepancies in its Server Extensions configuration. Right-click your virtual directory's name, and select All Tasks, Check Server Extensions. The Check Web dialog box appears with the message Figure 6 shows; click Yes.
12. Exit ISM or the Internet Information Server snap-in. Use Windows Explorer to drag the Web application's folders and files to the newly created directory.

If you don't have the contents of an existing Web application to use to test debugging, locate Session_VBScript.asp. This file is part of the standard IIS 5.0 installation on Windows 2000, and you can find it in the \inetpub\iissamples\sdk\asp\applications directory. Drag the file to the newly created directory. Session_VBScript.asp is a standalone Active Server Pages (ASP) file that serves as a great test for debugging.

You now have a Visual InterDev environment ready for debugging. Let's put it into action.

Putting IIS Debugging into Action
When you open the Visual InterDev project you just created, you can add the files and folders of the Web application to your Visual InterDev project. To add your folders, right-click the project name, then select New Folder. To add your files (or .asp files such as Session_VBScript.asp), right-click the project name, then select Add, Items. Next, locate the start file for your Web application (e.g., default.asp or default.htm). From Visual InterDev, right-click the start file and click Set As Start Page.

Now, choose an .asp file in your Web application that you want to debug. Edit the .asp file by opening it within your Visual InterDev project. Select a location in which you want the debugger to break—in other words, stop your .asp file in the middle of its operation to examine the values of any variable it might be using. To stop the .asp file, enter the reserved word STOP within a section of server-side ASP code. You can quickly identify the server-side code within an .asp file by the delimiters <% and %>, which Visual InterDev highlights in yellow. Save the file.

Press the F5 key (or choose Debug, Start from the Visual InterDev menu), and you're off and running. The message that Figure 7 shows will appear. Click Yes. (This message appears only once.) Then, the Debugging: Name and Password Required dialog box appears, which tells you that you've succeeded in setting up ASP debugging on this project.

After you authenticate, you can examine the values of variables that are being used in the Web application. Notice that your browser is in a suspended state, waiting for Visual InterDev to act. The real power of this kind of debugging is that it lets developers see the values of many of the variables. In this way, they can find out whether a DLL they're using is passing them the kind of values they expected, and if not, debugging can help them figure out what's needed. Visual InterDev debugging also allows a closer look at the routines' step-by-step processes, which is a tremendous help in weeding out the bugs in code under development.

For example, from Visual InterDev, choose View, Debug Windows, Immediate. In the Immediate dialog box, type the name of a variable that the .asp file you're debugging is using preceded by the print statement for VBScript, which is a question mark (?), such as

"? Session("SessionCountVB")")

Visual InterDev outputs the value of the variable to the immediate window, as Figure 8 shows.

Debugging Makes Development Easier
Although setting up Visual InterDev for debugging is a lengthy process, the increased environmental control that this kind of debugging affords software developers is well worth the effort. For more information about configuring IIS debugging in Visual InterDev, go to http://msdn.microsoft.com/vinterdev/technical/articles/debugging.asp. Next month, I'll show you how to set up, configure, and use the Win2K Indexing Service on the Internet and on your corporate LAN, intranet, and extranet.

Note: If your instructions include a step to clear the FrontPage Server Extensions check box, ignore them. Earlier versions of the Help documentation erroneously include this step.

Note: You don't actually need to add STOP statements within your .asp files. Because debugging is working correctly, you can simply set breakpoints by choosing the line on which you want to break and selecting Debug, Insert Breakpoint from the Visual InterDev menu. You can also click in the left margin of your ASP editing page, which inserts a breakpoint and leaves a large black dot in the margin. Click the black dot to remove the breakpoint.