Maximizing.ASP.dot.NET.Real.World.ObjectOriented.Development [Electronic resources] نسخه متنی

The Debugger

The debugger in Visual Studio is one of the most under-appreciated features of the product among Web developers. The debugger enables you to "spy" on your code in the middle of its execution cycle and see the decisions it makes and the values of every object in the code. Windows developers have enjoyed this debugging capability for a long time, and now it's just as straightforward for Web jockeys.

Using the debugger is fairly simplejust push F5 or click Debug -> Run from the menu, and you're on your way. The default page will run, and the debugger will "attach" to ASP.NET. At this point, you can do anything you might normally do with your running application. The excitement occurs when the debugger encounters a break point in your code, a notification to the debugger that it should stop the execution so you can see what's going on. You set a break point by clicking in the left margin next to your code.

Figure 14.3 shows the debugger in action. The small red sphere is a break point.

When the debugger hits a break point, you can either continue by pressing the continue button (shaped like a play button) or press F5. Even more useful, you can step through the code one line at a time by pressing F11. The line with the arrow in Figure 14.3 shows where the debugger currently is in the code. Every press of F11 will move to the next line, opening other class files if it has to show you where the execution is going.

While you're stepping through the code, you can explore the value of every object that currently exists in the context of this execution. In our example screen, you can see that simply mousing over the Response object has enabled us to drill down through properties and sub-properties. You can do virtually the same thing in the Locals window at the bottom of the screen. In fact, if any of those objects changes when you step into the next line of code, that object's name changes color to let you know.

This means of debugging is a lot easier than placing trace.Write() statements in your code, and it gives you the big picture of everything happening during code execution.