Visual InterDev

Debugging Remotely

See Also

In addition to debugging scripts and processes that are running on your computer, you can debug those that are running on another computer. This is referred to as remote debugging. In Microsoft^® Visual InterDev™, remote debugging is useful for debugging server scripts running in ASP pages on Microsoft^® Internet Information Server (IIS).

Note   If you are writing ASP pages that use the scripting object model, you can also set options that help you find errors and trace events. For details, see Debugging Script Objects in ASP Pages.

Ordinarily, to debug server script in an ASP page, you would have to install Visual InterDev on the server and then debug scripts locally on that server. However, with remote debugging, you can attach the debugger running on your computer to a script running on the server and issue debugging commands across the network.

Note   If IIS and Visual InterDev are running on the same computer, you can debug server scripts using that copy of Visual InterDev, without remote debugging.

For the most part, remote debugging is similar to debugging locally, except for these differences:

• You must perform some extra setup steps before you can use remote debugging.
  
  
• Only one user can use remote debugging on a server at a time.

The information below explains how to set up remote debugging, and then how to establish a remote debugging session.

Setting Up Remote Debugging

To use remote debugging, you must perform several setup steps. The first step is to be sure that the proper debugging components have been installed on the server. A full server installation of the Visual InterDev will normally load the proper components. However, if you did not perform a full server installation, or if you are not sure, you can follow the procedure below.

To install debugging components on the server

1. On the server computer, start the Visual Studio Enterprise Edition setup program.
   
   
2. Under Add/Remove Options, choose Server Applications and Tools.
   
   
3. On the next page, select Launch BackOffice Installation Wizard, and then choose Install.
   
   
4. When the BackOffice Business Solutions wizard is displayed, choose Custom and then choose Next.
   
   
5. Proceed until you see the page offering you a list of components to install. Uncheck all components except the following:
   • Remote Machine Debugging
     
     
   • Visual InterDev Server
6. Proceed with the installation.

To debug remotely, you must be able to provide the name and password of a Windows NT^® user who has administration privileges for the server. All developers who will be using remote debugging should be established as administration-level users on the server computer. Use Windows NT facilities on the server to specify administration privileges for all users who will be debugging remotely.

Remote debugging uses Distributed COM (DCOM) to communicate between the client and server computers. You must therefore configure DCOM on the server to allow a remote user to attach the debugger to a process there.

To configure DCOM on the server for remote debugging

1. From the Windows^® Start menu on the server, choose Run, and then in the Open box type Dcomcnfg.exe at the prompt.
   
   
2. In the Distributed COM Configuration Properties window, select Machine Debug Manager, and then choose Properties to display the Machine Debug Manager Properties dialog box.
   
   
3. In the Security tab, choose Use custom access permissions, and then choose Edit.
   
   
4. In the Registry Value Permissions dialog box, verify that Allow Access is selected in the Type of Access list, and then choose Add.
   
   
5. In the Add Users and Groups dialog box, select the server's name from the List Names From list. The server name typically is in the form \\server and appears at the top of the list.
   
   
6. Under Names, choose Administrators, choose Add, and then choose OK.
   
   
7. Return to the Security tab, choose Use custom launch permissions, and then choose Edit.

   Verify that Allow Launch is selected in the Type of Access list, choose Add, and then add administrators as you did in Steps 4 through 6.

8. Return to the Distributed COM Configuration Properties window, select MTS Client Export, and then choose Properties. Repeat Steps 4 through 7.
   
   
9. Return to the Distributed COM Configuration Properties window, select Catalog Class, and then choose Properties. Repeat Steps 4 through 7.

Enabling Debugging for ASP Pages

Before you can debug remotely, you must enable ASP debugging. You can manually enable debugging for your ASP application as described under "Enabling ASP Debugging on the Server" in the Troubleshooting topic. Alternatively, Visual InterDev can automatically enable debugging on the server as needed.

To automatically enable script debugging in ASP pages

1. In the Project Explorer, right-click the project and choose Properties to display the Property Pages dialog box.
   
   
2. Choose the Launch tab.
   
   
3. Under Server script, make sure both options, Automatically enable ASP server-side debugging on launch and Automatically enable ASP client-side debugging on launch, are checked.

When this option is set for your project, each time you start a debugging session, Visual InterDev checks that the server is appropriately configured for debugging. This includes:

• Setting the IIS application to run in its own memory space (in COM terms, it runs "out of process").
  
  
• Enabling the IIS application's debugging options.
  
  
• Setting up a Microsoft Transaction Server (MTS) package to allow you to attach the debugger to the Web application. The package's identify is set when you first start the debugging session by asking you to provide your name and password.

  Note   You can perform the first two steps manually on the server. For details, see "Enabling ASP Debugging on the Server" in the Troubleshooting topic.

When you quit your debugging session, Visual InterDev restores the server debugging settings and out-of-process setting to their previous values.

Running the Debugger Remotely

After the server has been configured for remote debugging, you can debug on the server in much the same way you do locally.

Note   It is highly recommended that you do not use Active Desktop mode of Microsoft^® Internet Explorer 4.0 when you are debugging.

There are two ways to start remote debugging:

• Launch a project using the debugger   This works just like debugging locally, except that Visual InterDev automatically attaches the debugger to the server and starts remote debugging.
  
  
• Attach to a process that is already running on the server   This is useful if you become aware of a server script problem while the application is running. You can detect an error in server script if the server returns error text instead of your page, or if the browser appears hung when you request an .asp file.

If you launch a project using the debugger, you can start debugging at the first line of script. Otherwise, you will only be able to debug script that runs after you attach to the process. In addition, if you launch a project, you will be able to edit the files you are debugging. When you attach to a process, you can see the files you are debugging, but cannot edit them there.

Note   Because remote debugging ties up process threads on the server, it is recommended that while a remote debugging session is in progress, other users avoid using the server.

Launching Remote Debugging

You launch remote debugging from within Visual InterDev.

Note   Before debugging server script, make sure you have enabled debugging as described above.

To launch a project using the debugger

1. In Visual InterDev, open the file to debug, and if needed, set breakpoints.
   
   
2. Make the page your project's start page. In the Project Explorer, right-click the page and choose Set as Start Page.
   
   
3. From the Debug menu in Visual InterDev, choose Start.

Note   If another user is already debugging on the server, Visual InterDev displays an error message and you will not be able to start the debugger.

4. If this is the first time you have started the debugger since opening the current project, you are prompted to provide user information used to identify the debugging process on the server.

   Enter the domain and name (in the form domain\name) and password of a user with administrative privileges. For more details, see Setting Up Remote Debugging earlier in this topic.

5. After the debugger starts and attaches to the document, proceed with debugging as normal.

Attaching to a Running Process

If debugging is already enabled on the server for your project and you detect an error while the application is running, you can attach the debugger to it.

Note   For information about setting server debugging options, see "Enabling ASP Debugging on the Server" in the Troubleshooting topic.

To attach to a running process

1. If it is not already open, start Visual InterDev.
   
   
2. From the Debug menu, choose Processes.
   
   
3. In the Processes dialog box, type the name of the computer to attach to. If you don't know the computer name, choose Machine and use the Browse for Computer dialog box to locate the server where you want to debug.
   
   
4. In the machine processes list, select your project, and then choose Attach.

   The process you selected appears in the Debugged Processes list.

5. Close the Processes dialog box and use the Running Documents window to select the ASP page to debug.

   You can step through scripts and test variables and expressions normally. However, to run a page you must navigate to it in your browser. In addition, you cannot edit the pages that you are debugging.