Visual Debugger allows you to examine code while it is running and includes features that help you debug applications, including the following:

• BreakpointsВ В В Breakpoints are places in the code where the debugger will stop the application, allow you to view the current data state of the application, and then step through each line of code. For information, see Debugging Basics: Breakpoints.

• SteppingВ В В Once you have stopped at a breakpoint, you can run the code line by line (known as stepping through the code). Visual Debugger includes a number of features to help you step through your code, such as iterators that allow you to specify how many times to step through a loop before stopping again. For more information, see Code Stepping Overview.

• Data ViewingВ В В Visual Debugger gives you many different options for viewing and tracking data while the application is running. The debugger allows you to modify the data while the application is stopped in break mode and then continue to run the application with the modified data. For more information, see Viewing Data in the Debugger.

Note
The Edit and Continue feature of Visual StudioВ 2005 is not available for Web applications.

For more information, see Using the Debugger with Web Pages.

To enable debugging for an ASP.NET Web application, you must configure the application to compile into a debug build. A debug build includes information that the debugger needs so that it can step through your code and display the contents of variables. You configure your Web application for debug builds in the Compilation section of your application's Web.config file. For more information, see compilation Element (ASP.NET Settings Schema). Alternatively, if you want to debug only single pages, you can add debug=true to the @ Page directive on the pages that you wish to debug. For more information, see How to: Enable Debugging for ASP.NET Applications.

Note
An application compiled into a debug build will perform considerably more slowly than if it is compiled into a retail build. Be sure you have debug mode turned off before you deploy your application. Additionally, in debug mode, more information is exposed in the stack when an error occurs and can be a potential security issue.

If you are running a Web server locally, such as IIS, you can debug applications running locally on your computer so that you can view your pages in a browser.

If you cannot run a page locally, because you cannot run a Web server or because the application is not available to you locally, you can debug an application running on another server. In order to debug remotely, you must install the Visual Studio remote debugging components on the remote server. For more information, see How to: Set Up Remote Debugging.

Debugging a process requires more privileges than running it. Therefore, in addition to configuring your application for debugging, you must also ensure that you have adequate permissions to attach to a process in order to debug it. Users have the permission to debug processes running under their own user local identity, but they cannot debug other user's processes. Administrators can debug any process.

To debug on a remote server, you need administrator privileges on the computer where the process to be debugged runs. For more information, see How to: Debug Web Applications on a Remote Server.

In addition to server-side application debugging, Visual Debugger allows you to debug client script written in ECMAScript (JavaScript) or VBScript. Client-script debugging can be especially useful when you have Web server controls that use client-side script. For more information, see Client-Side Script Debugging Roadmap and How to: Enable Client-Side Script Debugging.

Tasks

Reference

Concepts

Other Resources