The QuickWatch window is very similar to the other watch windows. However, it allows you to focus on a single variable or expression. The QuickWatch window is used less often now that DataTips exist. From the QuickWatch window, you can write expressions and add them to the watch window. When writing your expression, you have access to IntelliSense. Figure 9.31 shows the QuickWatch window.
The item you add to QuickWatch will be evaluated when you click the Reevaluate button. Clicking the Add Watch button will send the variable to the watch window.
In prior versions of Visual Studio, you could highlight a section of code and view a ToolTip that indicated the value of the variable or expression. In 2005, this concept is expanded considerably with DataTips. DataTips allow you to highlight a variable or expression in the code editor and get watch information right there in the editor. This feature is more how developers work. For example, if you are looking at a line of code, you might highlight something in that line to evaluate it. Previously, this meant doing a QuickWatch. Now it simply unfolds in a DataTip.
Figure 9.32 provides an example. Here, the cursor is positioned over the cust variable that is of type Customer. Clicking on the plus sign to expand this variable unfolds the many members of the object. You can scroll through this list using the arrow at the bottom of the window. You can also right-click any member in the list and edit its value, copy it, or add it to the watch window. The magnifying glass icon next to the items in the list allows you to select a specific visualizer for a given item (more on these shortly).
You can still select an expression and have it evaluated as a DataTip. For example, if you select the portion of line 39 in Figure 9.32 that reads (bool)custDr["contact_via_email"], a DataTip will show this variable and its value of true.
Tip
The DataTips window can often get in the way of viewing code. Sometimes, you need to see the DataTips and the code underneath. In this case, holding the Control (Ctrl) key will make the DataTips window transparent for as long as you press it.
When you are looking at variable values, what you really want to get to is the data behind the object. Sometimes this data is obscured by the object model itself. For example, suppose you are looking for the data that is contained in a DataSet object. To find it, you have to dig many layers deep in a watch window or a DataTip. You have to traverse the inner workings of the object model just to get at something as basic as the data contained by the object. If you've spent much time doing this in prior versions of Visual Studio, you know how frustrating it can be.
Visual Studio 2005 tries to take away this frustration and provide quick, easy access to the data contained in an object. It does so through a new tool called visualizers. Visualizers are meant to present the object's data in a meaningful way.
A few visualizers ship with Visual Studio by default. They include the following:
HTML Shows a browser-like dialog box with the HTML interpreted as a user might see it
XML Shows the XML in a structured format
Text Shows a string value in an easy-to-read format
DataSet Shows the contents of the DataSet, DataView, and DataTable objects
There is also a framework for writing and installing visualizers in Visual Studio. You can write your own and plug them into the debugger. You can also download additional visualizers and install them. The possibilities of visualizers are many: as many ways as there are to structure and view data. A few ideas might be a tree-view visualizer that displays hierarchical data or an image visualizer that shows image data structures.
You invoke a visualizer from one of the many places you view data values. This includes watch windows and DataTips. Visualizers are represented by a magnifying glass icon. Figure 9.33 shows launching a visualizer using this icon.
For a visualizer example, refer to the DataSet problem. Rather than digging through the object hierarchy to get at the data, you can now invoke the DataSet visualizer right from a DataTip. Figure 9.34 shows the visualizer in action for the customer DataSet object in the sample application.
Edit and Continue allows you to change code as you debug without killing your debug session. You can make a modification to a line of code or even fix a bug and keep working in break mode. Visual Basic developers who worked in versions prior to .NET should recall this powerful tool. Its absence in .NET made it one of the most requested features. The good news is that Edit and Continue was added in 2005 to both Visual Basic and C#.
There is no trick to invoking Edit and Continue. You simply make your code change during a debug session and then keep running through your code with a Step command or Continue.
The feature is turned on by default. If it is turned off, you can re-enable it using the Options dialog box available from the Tools menu.
Not all code changes you make are eligible for Edit and Continue. In fact, it should be used only in minor fixes. Any major additions to your code should not be done in debug mode just as a best practice. If your change is within the body of a method, it has a higher likelihood of passing the Edit and Continue test. Most code changes outside the method body require the debugger to restart. Some common changes that are not eligible for Edit and Continue include
Changing code on the current, active statement
Changing code on any calls on the stack that lead to the current, active statement
Adding new types, methods, fields, events, or properties
Changing a method signature
For a more exhaustive list, search MSDN for "Edit and Continue." There are similar lists for both Visual Basic and C#.
Remote debugging allows you to connect to a running application on another machine or domain and debug that application in its environment. This is often the only way to experience errors that are occurring on specific hardware. We've all heard the developer's cry, "Works on my machine." Remote debugging helps those developers figure out why their application doesn't work in other environments.
In a number of scenarios, remote debugging makes a lot of sense. They include debugging SQL serverstored procedures, web services, web applications, remote services or processes, and so on.
The hardest part about doing remote debugging is getting it set up properly. The actual debugging is no different from the debugging we've discussed thus far. However, the setup requires you to jump through a lot of hoops in terms of installation and security. These hoops are necessary because you do not, by default, want developers to easily connect debug sessions to applications on your servers.
There is some good news. Visual Studio 2005 tries to minimize and simplify the setup and configuration of remote debugging. Microsoft has introduced the Remote Debugging Monitor (msvsmon.exe) for this purpose. However, developers will still find the setup tasks somewhat arduous (but rewarding when finished). We will not cover the setup in great detail here. We suggest querying MSDN for "Remote Debugging" to get the full walkthrough.
We do offer the following, however, as a set of high-level tasks that you will need to complete to get remote debugging working:
Install the remote debugging monitor (msvsmon.exe