The tracing support built into ASP.NET works really well and is a great way to debug your application—especially
once it is deployed. However, when you're in development mode, having
to plant tracing messages in your page and then run it to see what
happens is cumbersome and sometimes not the most efficient way of
debugging. Microsoft Visual Studio provides excellent debugging
support through the environment, and you can use it to watch your code
execute and to step through the code one line at a time. In fact, you
have access to all of the Visual Studio debugging facilities, even
though you're developing Web applications.
Remember, ASP.NET and Visual
Studio work in concert to make you feel like you're doing desktop
application development, even though you are developing Web
applications. That goes for the debugger as well. The following exercise
familiarizes you with the Visual Studio debugging environment.
Debugging an application
Open the DebugORama Web site. To support debugging, web.config needs to include the correct setting. You can type the debugger setting manually if you wish; however, Visual Studio will insert it for you once you start debugging. <system.web>
<compilation debug="true"/>
</system.web>
Open the TraceMe.aspx page and insert breakpoints in Page_Load, AssembleTable, and Button1_Click. You can insert breakpoints
by highlighting a line in the editor window and pressing the F9 key.
You can also click Debug, Toggle Breakpoint on the main menu or simply
click the light gray ribbon to the left of the text in the code editor
(where the breakpoints are indicated). Visual Studio will show a big red
dot to the left of the breakpoint lines, as shown in the following
graphic:
Start debugging by pressing the F5 key. You can also debug by clicking Debug, Start Debugging on the main menu. If debugging is not
turned on in the web.config file, Visual Studio will ask you before it
sets the debugging attribute. Visual Studio will start running the site.
When it comes to your breakpoints, Visual Studio will stop execution
and highlight the current line in yellow in the window, as shown here:
In this example, Page_Load is the first breakpoint Visual Studio encounters. At this point, you can start stepping through the code. Press F10 to step overmethods, and press F11 to step into methods. Alternatively, you can click Debug, Step Over and Debug, Step Into on the main menu or use the corresponding toolbar buttons. Rest the mouse pointer on any variables you see. Notice how Visual Studio displays the value of the variable in a tooltip. Press F5 to resume the program. Visual Studio runs until it hits another breakpoint. Run through all the breakpoints. Next, post back to the server using the button. Notice the breakpoints are hit again. Also notice that first the Page_Load is hit, and then the Button_Click handler. This highlights the ephemeral nature of a Web page. A new page is being created for each request that comes in. Finally,
try out a couple of the debug windows. You can monitor various aspects
of your program by clicking Debug, Window on the main menu and selecting
the window. Here is the Locals window, showing those variables in local scope:
The Call
Stack window, as depicted in the following graphic, shows how execution
finally arrives at this spot. You can trace through and follow the
entire program execution up to this point.
Other notable windows include the Watch window, where you can examine any variable you want, and the Threads window, where you can see how many threads are running, what their thread IDs are, and so forth.
|
