You debug an IIS application in the same way you do any other Visual Basic application — by entering run mode from Visual Basic. Visual Basic loads the webclass run time, creates the virtual root from which to run the .asp file for the application, if necessary, and launches the system's default browser with an HTTP reference to the .asp file. The .asp file, in turn, launches the webclass.
Note Although you can view the .htm files associated with your application in the browser by opening them from the browser's File menu, this is not debugging your application. You must use the Start option from Visual Basic to enter debugging mode.
When you debug, you have the full Visual Basic development environment at your disposal. You can use all the tools available in Visual Basic — breakpoints, watch variables, debug statements, and so on — to debug your project.
Visual Basic prompts you when you debug that it is going to create a virtual directory for your project. A virtual directory is a directory outside your Web server's home directory that appears to browsers as a subdirectory of the home directory. It allows you to publish contents to the Web from directories outside the home directory structure. You cannot change the location of the virtual directory Visual Basic creates for the webclass.
The Project Properties dialog box's Debugging panel settings determine whether the system waits for you to tell it what to do when you go into run mode or automatically starts the webclass you specify. When you choose to automatically start the webclass, Visual Basic launches Internet Explorer, navigates to the URL for your application, and fires the webclass's BeginRequest event.
Visual Basic deletes all temporary files when it comes out of run mode. In addition, it destroys the instance of the Webclass Designer and restarts the designer in design mode.
For More Information See "Debugging Your Code and Handling Errors" in the Programmer's Guide for more information on how to test and debug your IIS application.
You can use Visual Basic's error-handling features in your IIS applications to trap errors and take corrective action. When an error occurs, Visual Basic sets the various properties of the error object, Err, such as an error number or a description. You can use the Err object and its properties in an error-handling routine so that your application can respond intelligently to an error situation.
In addition to standard error handling, IIS applications allow you to use two special features to handle errors:
For More Information The basics of error handling are discussed in "Debugging Your Code and Handling Errors," in the Programmer's Guide. For information specific to ActiveX projects, see "Generating and Handling Errors in ActiveX Components", in "Building Code Components," in the Components Tools Guide.
You can use the Trace method to help identify errors during the debug process and to track performance and statistical data. The Trace method sends a specified string to the Win32 OutputDebugString API. The string can then be captured to a suitable debugging tool such as DBMON.
Using the Trace method can allow you to debug on your production server computer and record useful information such as information about the execution of the application, error messages that occur, and any other information you need.
For More Information See "Trace Method" in the Language Reference for more information on using this method in your error handling.
A fatal error on a webclass is one from which the application cannot recover or restore the appropriate webitem. For example, a fatal error might be an unhandled error within a webclass event, a structural error, or an unexpected error within the run-time DLL. Following such an error, the webclass run time fires the FatalErrorResponse event. The application is terminated and the instance of the webclass is destroyed.
When a fatal error occurs, the application can write a message to the Response object in the handler for the FatalErrorResponse event. This message can be one that you write, or it can be the default message for the .asp file associated with the webclass. To write your own message, use the Response object, then set the senddefault argument of the FatalErrorResponse event to False. To use the default error message, leave the senddefault argument set to True.
Note The webclass run time provides an Error property that is only available from within the FatalErrorResponse event. This property returns an object that describes the error that caused the webclass to terminate.
The webclass run time also logs fatal errors to the NT event log. On Windows 95 systems, the run-time DLL creates a log file in the Windows directory and logs the error there.
For More Information See "FatalErrorResponse Event" in the Language Reference for more information on handling nonrecoverable errors.