Microsoft Visual InterDev includes a powerful debugging tool that works with other Visual Studio debugging features. But using the Visual InterDev debugging tool can challenge even the most savvy developer's ability to troubleshoot an application. By studying the lessons I learned recently while trying to make the Visual InterDev debugger work, you might save time and trouble in debugging your Web application.
After recently encountering a problem with a Web application, I tested the application and received an error message reporting that an ADO error occurred on line 31 of the DatabaseClass.asp file. The reported error showed a problem with the parameters passed to the ADO Command object.
To debug the application, I started Visual InterDev and opened the application's source code. Then I right-clicked the page that generated the error and selected Set as Start Page. Next, I opened the properties for the Visual InterDev project by right-clicking the project name and selecting properties, which opened the IDispWebProject Properties dialog box. Then I selected the Launch tab and checked the Automatically enable ASP server-side script debugging on launch check box. Next, I clicked OK and pressed F5 to start the application in debug mode. That's when the fun started. Visual InterDev displayed the message
Unable to set server into correct debugging state automatically. You may not be able to debug ASP pages.
This message meant that I hadn't correctly configured the server running IIS for debugging applications. I ran through a checklist of potential configuration problems. The application I was debugging was on my workstation, so I didn't need remote debugging support. The workstation was running a new installation of Windows 2000, which meant that I had implemented a new installation of IIS and Visual Studio.
Next, I searched Microsoft's Web site for information about debugging with Visual InterDev. I found the article "Microsoft Visual InterDev 6.0 Debugging" (http://msdn.microsoft.com/library/techart/msdn_videbugging .htm). This article provides a summary of the steps you need to take to set up the debugger. First, download the files associated with the article (you'll find the link near the top of the article). Double-click the 5257.exe file and extract the files to a folder. One of these files, the viddbg.exe utility, is vital when you're resolving problems related to the Visual InterDev debugging feature. You use this utility to check the status of the Visual InterDev installation.
Next, open a command prompt window and navigate to the directory that contains viddbg.exe. Run the following command:
C:\util\VIDDBG /Server > debugstatus.txt
This command runs the viddbg.exe utility, which tests the status of the Visual InterDev server configuration and places the test results in a file called debugstatus.txt. I usually give this file the name of the system I'm testing.
Listing 1 shows the results of this test on my system. You can see from the asp.dll version information that the utility can't discern the version number for the ASP DLL. I ran the viddbg.exe file on a Win2K Professional system, but Microsoft designed the utility to run on Windows NT 4.0, so I deduced that this discrepancy prevented the utility from extracting the file version information. You can see from the message in Listing 1 that debugging requires an ASP file with version 4.02.0622 or later. I used Windows Explorer to check the asp.dll version on my system. I knew that the version I found, 5.0.2180.1, wasn't the source of the problem because it was a later version than 4.02.0622.
The error message The system cannot find the file specified under the section VID Server Components reveals the source of my problem. This message usually means that someone didn't set up the Visual InterDev server extensions correctly. The summary message at the end of the listing indicates that the server components also weren't installed correctly.
When you encounter a machine that the Visual InterDev Debugger won't work on, the server component setup is the most likely source of the problem. Before you spend time wrestling with the Microsoft technical article I mentioned earlier, try to fix the problem by installing or reinstalling the Visual InterDev server extensions, which are a component of the Microsoft BackOffice installation wizard. However, if you have already installed SQL Server and the other features you need on your workstation, you can install the Visual InterDev server extensions directly from Visual InterDev's standalone setup, which you'll find in the Vid_ss directory on CD-ROM 1 of Visual InterDev Professional Edition, or CD-ROM 2 of Visual Studio Professional or Visual Studio Enterprise Edition. Run setup.exe from this directory; the executable file will install the Visual InterDev server extensions within a few minutes. Next, reinstall Visual Studio Service Pack 3 (SP3), which will update the server components that you just installed. You don't need to make any other system changes as long as you're using the debugger on the local system where IIS and your ASP application are running.
You're ready to test the debugger. Start Visual InterDev and load your Web application. Next, right-click the page that you want to start the debugging process with and select Set as Start Page. Next, right-click the Visual InterDev project name, and select Properties. Select the Launch tab, and select Automatically enable ASP server-side script debugging on launch. Click OK to close the properties window. Open the page you're testing and set a breakpoint by clicking in the left border of the code window. Press F5 to start the application in debug mode.
I followed these steps with my stalled application and quickly found the problem. Figure 1 shows the Visual InterDev debugger with the cursor stopped on the line with the breakpoint (the highlighted line). This is line 31, which the error page reported as having the error. In the Immediate pane, which is at the bottom of Figure 1, I entered a question mark (?) character followed by the name of the variable and pressed Enter to display the results of the variable. Figure 1 shows that the ? command in the Immediate window returned nothing; the variable is empty, and this missing value caused the ADO error. The variable is empty because adCmdText is a constant that ADO provided. The constant doesn't have a value, so ADO isn't working. To fix this problem, I selected Project References from the Project menu, selected Microsoft ActiveX Data Objects 2.5 Library, and clicked OK.
Setting a project reference in Visual InterDev places a line in the global.asa file that links the ADO type library into the global.asa file, making any constants in the file available to the ASP application at runtime. With this modification, I can use the constants in my ASP code without having to use an include file to load them.
If you're running Win2K, you only need to install the Visual InterDev server extensions to make the Visual InterDev debugger work on a local machine. If you're running Windows NT 4.0, then you also need to install NT SP4 or later to get the correct version of the ASP DLL and the patch for IIS that enables the debugger to work. Also, note that debugging doesn't work on Windows 9x. And finally, note that Microsoft suggests that you conduct debugging on a local system where both Visual InterDev and IIS are running. Remote debugging works, but it's a slow and problematic process.
Visual InterDev's debugging features provide a great service to Web developers, especially those who build data-driven applications. The debugger works especially well when you use it on a local system.
