Chapter 3: From 2003 to 2010: Debugging an Application

This chapter is taken from book "Moving to Microsoft Visual Studio 2010" by Patrice Pelland, Pascel Pare, and Ken Haines published for Microsoft Press.

After reading this chapter on debugging, you will be able to

• Use the new debugger features of Microsoft Visual Studio 2010
• Create unit tests and execute them in Visual Studio 2010
• Compare what was available to you or see what was different for you as a developer in Visual Studio 2003

As we were writing this book, we realized how much the debugging tools and developer aids have evolved over the last three versions of Visual Studio. Focusing on debugging an application and writing unit tests just increases the opportunities we have to work with Visual Studio 2010.

Visual Studio 2010 Debugging Features

In this chapter, you'll go through the different debugging features using a modified Plan My Night application. If you installed the companion content at the default location, you'll find the modified Plan My Night application at the following location: %userprofile%\Documents\Microsoft Press\Moving to Visual Studio 2010\Chapter 3\Code. Double-click the PlanMyNight.sln file.

First, before diving into the debugging session itself, you'll need to set up a few things:

1. In Solution Explorer, ensure that PlanMyNight.Web is the startup project. If the project name is not in bold, right-click on PlanMyNight.Web and select Set As StartUp Project.
    
2. To get ready for the next steps, in the PlanMyNight.Web solution open the Global.asax.cs file by clicking the triangle beside the Global.asax folder and then double-clicking the Global.asax.cs file as shown in Figure 3-1.
   
   
   
   FIGURE 3-1 Solution Explorer before opening the file Global.asax.cs

Managing Your Debugging Session

Using the Plan My Night application, you'll examine how a developer can manage and share breakpoints. And with the use of new breakpoint enhancements, you'll learn how to inspect the different data elements in the application in a much faster and more efficient way. You'll also look at new minidumps and the addition of a new intermediate language (IL) interpreter that allows you to evaluate managed code properties and functions during minidump debugging.

New Breakpoint Enhancements

At this point, you have the Global.ascx.cs file opened in your editor. The following steps walk you through some ways to manage and share breakpoints:

1. Navigate to the Application_BeginRequest(object sender, EventArgs e) method, and set a breakpoint on the line that reads var url = HttpContext.Current.Request.Url; by clicking in the left margin or pressing F9. Look at Figure 3-2 to see this in action.



FIGURE 3-2 Creating a breakpoint

2. Press F5 to start the application in debug mode. You should see the developer Web server starting in the system tray and a new browser window opening. The application should immediately stop at the breakpoint you just created. The Breakpoints window might not be visible even after starting the application in debug mode. If that is the case, you can make it visible by going to the Debug menu and selecting Windows and then Breakpoints, or you can use the following keyboard shortcut: Ctrl+D+B.

Visual Studio 2003 Here is an area where there's a night-and-day difference between Visual Studio 2003 and Visual Studio 2010. Thankfully, the ease of debugging in Visual Studio 2010 is not comparable to the pain developers experienced in Visual Studio 2003.

Debugging Web applications in Visual Studio 2003 required you to complete a series of careful tasks to be successful. For instance, you had to enable debugging in a few different places in the Configuration Manager; you had to configure IIS carefully to avoid getting the dreaded Temporary ASP.NET Files Access Denied security exception. Basically, it was not developer friendly; it required lots of configuration and still there was no guarantee of success. Many articles were written to help solve the intricacies of debugging an ASP.NET Web application with Internet Information Services (IIS) 5 and 6 and Visual Studio 2003. A good reference that you might have consulted a few times is this one: http://msdn.microsoft.com/en-us/library/aa290100(VS.71).aspx . Many of those blogs or articles were just there to allow professional developers to debug on their workstations. Doing some research in online forums revealed how much folks like you were struggling for years through dozens of tough Web application debugging situations. For instance, debugging an ASP.NET application along with a few Web services was quite a challenge to set up.

The creation of the personal Web server (also known as "Cassini") improved things tremendously, but a few enhancements in Visual Studio 2010 make it easier to modify the necessary configuration files, modify project settings, and deploy to IIS. These improvements help developers write good code and and spend less time trying to debug it. You'll find that it definitely feels different to debug in Visual Studio 2010-you'll find it refreshing and easier.
You should now see the Breakpoints window as shown in Figure 3-3.




FIGURE 3-3 Breakpoints window

3. In the same method, add three more breakpoints so that the editor and the Breakpoints window look like those shown in Figure 3-4.



FIGURE 3-4 Code editor and Breakpoints window with three new breakpoints

Visual Studio 2003 As a reader and a professional developer who used Visual Studio 2003 often, you probably noticed a series of new buttons as well as new fields in the Breakpoints window in this exercise. As a reminder, take a look at Figure 3-5 for a quick comparison of what it looks like in Visual Studio 2003.



FIGURE 3-5 Visual Studio 2003 Breakpoints window

4. Notice that the Labels column is now available to help you index and search breakpoints. It is a really nice and useful feature that Visual Studio 2010 brings to the table. To use this feature, you simply right-click on a breakpoint in the Breakpoints window and select Edit Labels or use the keyboard shortcut Alt+F9, L. Take a look at Figure 3-6 as a reference.



FIGURE 3-6 Edit Labels option

5. In the Edit Breakpoint Labels window, add labels for the selected breakpoint (which is the first one in the Breakpoints window). Type ContextRequestUrl in the Type A New Label text box, and click Add. Repeat this operation on the next breakpoint, and type a label name of Url. When you are done, click OK. You should see a window that looks like Figure 3-7 while you are entering them, and to the right you should see the Breakpoints window after you are done with those two operations.



FIGURE 3-7 Adding labels that show up in the Breakpoints window

Note You can also right-click on the breakpoint in the left margin and select Edit Labels to accomplish the same tasks just outlined.

Note You'll see that when adding labels to a new breakpoint you can choose any of the existing labels you have already entered. You'll find these in the Or Choose Among Existing Labels area, which is shown in the Edit Breakpoint Labels dialog box on the left in Figure 3-7.

6. Using any of the ways you just learned, add labels for each of the breakpoints and make sure your Breakpoints window looks like Figure 3-8 after you're done.



FIGURE 3-8 Breakpoints window with all labels entered

When you have a lot of code and you are in the midst of a debugging session, it would be great to be able to filter the displayed list of breakpoints. That's exactly what the new Search feature in Visual Studio 2010 allows you to do.

7. To see the Search feature in action, just type url in the search text box and you'll see the list of breakpoint is filtered down to breakpoints containing url in one of their labels.

In a team environment where you have many developers and testers working together, often two people at some point in time are working on the same bugs. In Visual Studio 2003, the two people needed to sit near each other, send one another screen shots, or send one another line numbers of where to put breakpoints to refine where they should look while debugging a particular bug.

Important One of the great new additions to breakpoint management in Visual Studio 2010 is that you can now export breakpoints to a file and then send them to a colleague, who can then import them into his own environment. Another scenario that this feature is useful for is to share breakpoints between machines. We'll see how to do that next.

8. In the Breakpoints window, click the Export button to export your breakpoints to a file, and then save the file on your desktop. Name the file breakexports.xml.

9. Delete all the breakpoints either by clicking the Delete All Breakpoints Matching The Current Search Criteria button or by selecting all the breakpoints and clicking the Delete The Selected Breakpoints button . The only purpose of deleting them is to simulate two developers sharing them or one developer sharing breakpoints between two machines.

10. You'll now import your breakpoints by clicking the Import button and loading them from your desktop. Notice that all your breakpoints with all of their properties are back and loaded in your environment. For the purposes of this chapter, delete all the breakpoints.

Visual Studio 2003 Putting breakpoints in client-side code (JavaScript) and stopping and tracing was not really friendly. As a developer, you had to place a debugger (or stop in VBScript) statement in your client-side code and then trace into the code. But there was no IntelliSense support for client-side code. In Visual Studio 2010, you get great support for JavaScript as well as for the latest jQuery iteration. It was already good in Visual Studio 2008, but the integration in Visual Studio 2010 is faster and you don't have to do anything to get it.

Inspecting the Data

When you are debugging your applications, you know how much time one can spend stepping into the code and inspecting the content of variables, arguments, and so forth. Maybe you can remember when you were learning to write code, a while ago, when debuggers weren't a reality or when they were really rudimentary. Do you remember (maybe not-you might not be as old as we are) how many printf or WriteLn statements you had to write to inspect the content of different data elements.

Visual Studio 2010 From the days of Visual Studio 2003, there already was a big improvement from the days of writing to the console with all kinds of statements because we had a real debugger with new functionalities. New data visualizers allowed you to see XML as a well-formed XML snippet and not as a long string. Furthermore, with those data visualizers, you could view arrays in a more useful way, with the list of elements and their indices, and you accomplished that by simply hovering your mouse over the object. Take a look at Figure 3-9 for an example.



FIGURE 3-9 Collection view versus an array view in the debugger in Visual Studio 2010 and in Visual Studio 2003

Visual Studio 2003 In Visual Studio 2003, there was no other way to do data visualizations apart from Watch, Locals, and Quick Watch or some of the more rudimentary ways described earlier. You couldn't hover over a field in an array to get its content. If you had XML or formatted text in a string, you couldn't read it in any meaningful way other than opening Notepad or another file in Visual Studio and pasting the content of a string to see the formatted content of a variable.

Although those DataTip data visualization techniques are still available in Visual Studio 2010, a few great enhancements have been added that make DataTips even more useful. The DataTip enhancements have been added in conjunction with another new feature of Visual Studio 2010, multimonitor support. Floating DataTips can be valuable to you as a developer.Having the ability to put them on a second monitor can make your life a lot easier while debugging because it keeps the data that always needs to be in context right there on the second monitor.

The following steps demonstrate how to use these features:

1. In the Global.ascx.cs file, insert breakpoints on lines 89 and 91, lines starting with the source code var authority and var pathAndQuery, respectively.

2. You are now going to experiment with the new DataTip features. Start the debugger by pressing F5. When the debugger hits the first breakpoint, move your mouse over the word url and click on the pushpin as seen in Figure 3-10.



FIGURE 3-10 The new DataTip pushpin feature

3. To the right of the line of code, you should see the pinned DataTip (as seen in Figure 3-11 on the left). If you hover your mouse over the DataTip, you'll get the DataTip management bar (as seen in Figure 3-11 on the right).

FIGURE 3-11 On the left is the pinned DataTip, and on the right is the DataTip management bar

Note You should also see in the breakpoint gutter a blue pushpin indicating that the DataTip is pinned. The pushpin should look like this: . Because you have a breakpoint on that line, the pushpin is actually underneath it. To see the pushpin, just toggle the breakpoint by clicking on it in the gutter. Toggle once to disable the breakpoint and another time to get it back.

Note If you click on the double arrow pointing down in the DataTip management bar, you can insert a comment for this DataTip, as shown in Figure 3-12. You can also remove the DataTip altogether by clicking the X button in the DataTip management bar.



FIGURE 3-12 Inserting a comment for a DataTip

4. One nice feature of the new DataTip is that you can insert any expression to be evaluated right there in your debugging session. For instance, right-click on the DataTip name, in this case on url, select Add Expression, type authority, and then add another one like this: (authority != null). You'll see that the expressions are evaluated immediately and will continue to be evaluated for the rest of the debugging session every time your debugger stops on those breakpoints. At this point in the debugging session, the expression should evaluate to null and false, respectively.

5. Press F10 to execute the line where the debugger stopped, and look at the url DataTip as well as both expressions. They should contain values based on the current context. Take a look at Figure 3-13 to see this in action.




FIGURE 3-13 The url pinned DataTip with the two evaluated expressions

6. Although it is nice to be able to have a mini-watch window where it matters-right there where the code is executing-you can also see that it is superimposed on the source code being debugged. Keep in mind that you can move the DataTip window anywhere you want in the code editor by simply dragging it. Take a look at Figure 3-14 for an example.



FIGURE 3-14 Move the pinned DataTip away from the source code

7. Because it is pinned, the DataTip window stays where you pinned it, so it will not be in view if you trace into another file. But in some cases, you need the DataTip window to be visible at all times. For instance, keeping it visible is interesting for global variables that are always in context or for multimonitor scenarios. To move a DataTip, you have to first unpin it by clicking the pushpin in the DataTip management bar. You'll see that it turns yellow. That indicates you can now move it wherever you want-for instance, over Solution Explorer, to a second monitor, over your desktop, or to any other window. Take a look at Figure 3-15 for an example.



FIGURE 3-15 Unpinned DataTip over Solution Explorer and the Windows desktop

Note If the DataTip is not pinned, the debugger stops in another file and method, and the DataTip contains items that are out of context, the DataTip windows will look like Figure 3-16. You can retry to have the debugger evaluate the value of an element by clicking on this button: . However, if that element has no meaning in this context, it's possible that nothing happens.



FIGURE 3-16 DataTip window with out-of-context items

Note You'll get an error message if you try to pin outside the editor, as seen in Figure 3-17.

FIGURE 3-17 Error message that appears when trying to pin a DataTip outside the code editor

Note Your port number might be different than in the screen shots just shown. This is normal-it is a random port used by the personal Web server included with Visual Studio.

Note You can also pin any child of a pinned item. For instance, if you look at url and expand its content by pressing the plus sign (+), you'll see that you can also pin a child element, as seen in Figure 3-18.

FIGURE 3-18 Pinned child element within the url DataTip

8. Before stopping the debugger, go back to the Global.ascx.cs if you are not already there and re-pin the DataTip window. Then stop the debugging session by clicking the Stop Debugging button in the debug toolbar () or by pressing Shift+F5. Now if you hover your mouse over the blue pushpin in the breakpoint gutter, you'll see the values from the last debug session which is a nice enhancement over the watch window. Take a look at Figure 3-19 for what you should see.



FIGURE 3-19 Values from the last debug session for a pinned DataTip

Note As with the breakpoints, you can export or import the DataTips by going to the Debug menu and selecting Export DataTips or Import DataTips, respectively.

Using the Minidump Debugger

Many times in real-world situations, you'll have access to a minidump from your product support team. Apart from their bug descriptions and repro steps, it might be the only thing you have to help debug a customer application. Visual Studio 2010 adds a few enhancements to the minidump debugging experience.

Visual Studio 2003 In Visual Studio 2003, you could debug managed application or minidump files, but you had to use an extension if your code was written in managed code. You had to use a tool called SOS and load it in the debugger using the Immediate window. You had to attach the debugger both in native and managed mode, and you couldn't expect to have information in the call stack or Locals window. You had to use commands for SOS in the Immediate window to help you go through minidump files. With application written in native code, you used normal debugging windows and tools. To read more about this or just to refresh your knowledge of the topic, you can read the Bug Slayer column in MSDN magazine here: http://msdn.microsoft.com/en-us/magazine/cc164138.aspx.

Let's see the new enhancements to the minidump debugger. First you need to create a crash from which you'll be able to generate a minidump file:

1. In Solution Explorer in the PlanMyNight.Web project, rename the file Default.aspx to DefaultA.aspx. Note the A appended to the word "Default."

2. Make sure you have no breakpoints left in your project. To do that, look in the Breakpoints window and delete any breakpoints left there using any of the ways you learned earlier in the chapter.

3. Press F5 to start debugging the application. Depending on your machine speed, soon after the build process is complete you should see an unhandled exception of type HttpException. Although the bug is simple in this case, let's go through the steps of creating the minidump file and debugging it. Take a look at Figure 3-20 to see what you should see at this point.



FIGURE 3-20 The unhandled exception you should expect

4. It is time to create the minidump file for this exception. Go to the Debug menu, and select Save Dump As as seen in Figure 3-21. You should see the name of the process from which the exception was thrown. In this case, the process from which the exception was thrown was Cassini or the Personal Web Server in Visual Studio. Keep the file name proposed (WebDev.WebServer40.dmp), and save the file on your desktop. Note that it might take some time to create the file because the minidump file size will be close to 300 MB.



FIGURE 3-21 Saving the minidump file

5. Stop Debugging by pressing Shift+F5 or the Stop Debugging button.

6. Next, go to the File menu and close your solution.

7. In the File menu, click Open and point to the desktop to load your minidump file named WebDev.WebServer40.dmp. Doing so opens the Minidump File Summary page, which gives you some summary information about the bug you are trying to fix. (Figure 3-22 shows what you should see.) Before you start to debug, you'll get basic information from that page such as the following: process name, process architecture, operating system version, CLR version, modules loaded, as well as some actions you can take from that point. From this place, you can set the paths to the symbol files. Conveniently, the Modules list contains the version and path on disk of your module, so finding the symbols and source code is easy. The CLR version is 4.0; therefore, you can debug here in Visual Studio 2010.

FIGURE 3-22 Minidump summary page

8. To start debugging, locate the Actions list on the right side of the Minidump File Summary page and click Debug With Mixed.

9. You should see almost immediately a first-chance exception like the one shown in Figure 3-23. In this case, it tells you what the bug is; however, this won't always be the case. Continue by clicking the Break button.



FIGURE 3-23 First-chance exception

10. You should see a green line indicating which instruction caused the exception. If you look at the source code, you'll see in your Autos window that the controllerExport variable is null, and just before that we specified that if the variable was null we wanted to have an HttpException thrown if the file to load was not found. In this case, the file to look for is Default.aspx, as you can see in the Locals window in the controllerName variable. You can glance at many other variables, objects, and so forth in the Locals and Autos windows containing the current context. Here, you have only one call that belongs to your code, so the call stack indicates that the code before and after is external to your process. If you had a deeper chain of calls in your code, you could step back and forth in the code and look at the variables. Figure 3-24 shows a summary view of all that.



FIGURE 3-24 Autos, Locals, and Call Stack windows, and the next instruction to execute

11. OK, you found the bug, so stop the debugging by pressing Shift+F5 or clicking the Stop Debugging button. Then fix the bug by reloading the PlanMyNight solution and renaming the file back to default.aspx. Then rebuild the solution by going to the Build menu and selecting Rebuild Solution. Then press F5, and the application should be working again.

Web.Config Transformations

This next new feature, while small, is one that will delight many developers because it saves them time while debugging. The feature is the Web.Config transformations that allow you to have transform files that show the differences between the debug and release environments. As an example, connection strings are often different from one environment to the other; therefore, by creating transform files with the different connection strings-because ASP.NET provides tools to change (transform) web.config files-you'll always end up with the right connection strings for the right environment. To learn more about how to do this, take a look at the following article on MSDN: http://go.microsoft.com/fwlink/?LinkId=125889.

Creating Unit Tests

Most of the unit test framework and tools are unchanged in Visual Studio 2010 Professional. It is in other versions of Visual Studio 2010 that the change in test management and test tools is really apparent. Features such as UI Unit Tests, IntelliTrace, and Microsoft Test Manager 2010 are available in other product versions like Visual Studio 2010 Premium and

Visual Studio 2010 Ultimate. To see which features are covered in the Application Lifecycle Management and for more specifics, refer to the following article on MSDN: http://msdn.microsoft.com/en-us/library/ee789810(VS.100).aspx.

Visual Studio 2003 With Visual Studio 2003, your options to create unit tests and execute them were limited to third-party tools and frameworks like nUnit and other commercial products created by Microsoft partners.
In this part of the chapter, we'll simply show you how to add a unit test for a class you'll find in the Plan My Night application. We won't spend time defining what a unit test is or what it should contain; rather, we'll show you within Visual Studio 2010 how to add tests and execute them.

You'll add unit tests to the Plan My Night application for the Print Itinerary Add-in. To create unit tests, open the solution from the companion content folder. If you do not remember how to do this, you can look at the first page of this chapter for instructions. After you have the solution open, just follow these steps:

1. In Solution Explorer, expand the project PlanMyNight.Web and then expand the Helpers folder. Then double-click on the file ViewHelper.cs to open it in the code editor. Take a look at Figure 3-25 to make sure you are at the right place.



FIGURE 3-25 The PlanMyNight.Web project and ViewHelper.cs file in Solution Explorer

2. In the code editor, you can add unit tests in two different ways. You can right-click on a class name or on a method name and select Create Unit Tests. You can also go to the Test menu and select New Test. We'll explore the first way of creating unit tests. This way Visual Studio automatically generates some source code for you. Right-click the GetFriendlyTime method, and select Create Unit Tests. Figure 3-26 shows what it looks like.



FIGURE 3-26 Contextual menu to create unit tests from by right-clicking on a class name

3. After selecting Create Unit Tests, you'll be presented with a dialog that, by default, shows the method you selected from that class. To select where you want to create the unit tests, click on the drop-down combo box at the bottom of this dialog and select PlanMyNight.Web.Tests. If you didn't have an existing location, you would have simply selected Create A New Visual C# Test Project from the list. Figure 3-27 shows what you should be seeing.



FIGURE 3-27 Selecting the method you want to create a unit test against

4. After you click OK, the dialog switches to a test-case generation mode and displays a progress bar. After this is complete, a new file is created named TimeHelperTest.cs that has autogenerated code stubs for you to modify.

5. Remove the method and its attributes because you'll create three new test cases for that method. Remove the following code:

        /// <summary>
        ///A test for GetFriendlyTime
        ///</summary>
        // TODO: Ensure that the UrlToTest attribute specifies a URL to an ASP.NET page (for example,// http://.../Default.aspx). This is necessary for the unit test to be executed on the web server,// whether you are testing a page, web service, or a WCF service.
        [TestMethod()]
        [HostType("ASP.NET")]
        [AspNetDevelopmentServerHost("C:\\Users\\Patrice\\Documents\\Chapter
3\\code\\PlanMyNight.Web", "/")]
        [UrlToTest("http://localhost:48580/")]
        public void GetFriendlyTimeTest()
        {
            int totalMinutes = 0; // TODO: Initialize to an appropriate value
            string expected = string.Empty; // TODO: Initialize to an appropriate value
            string actual;
            actual = TimeHelper.GetFriendlyTime(totalMinutes);
            Assert.AreEqual(expected, actual);
            Assert.Inconclusive("Verify the correctness of this test method.");
        }

6. Add the three simple test cases validating three key scenarios used by PlanMyNight. To do that, insert the following source code right below the method attributes that were left behind when you deleted the block of code in step 5:

        [TestMethod]
        public void ZeroReturnsSlash()
        {
            Assert.AreEqual("-", TimeHelper.GetFriendlyTime(0));
        }
        [TestMethod]
        public void LessThan60MinutesReturnsValueInMinutes()
        {
            Assert.AreEqual("10m", TimeHelper.GetFriendlyTime(10));
        }
        [TestMethod()]
        public void MoreThan60MinutesReturnsValueInHoursAndMinutes()
        {
            Assert.AreEqual("2h 3m", TimeHelper.GetFriendlyTime(123));
        }

7. In the PlanMyNight.Web.Tests project, create a solution folder called Helpers. Then move your TimeHelperTests.cs file to that folder so that your project looks like Figure 3-28 where you are done.



FIGURE 3-28 TimeHelperTest.cs in its Helpers folder

8. It is time to execute your newly created tests. To execute only your newly created tests, go into the code editor and place your cursor on the class named public class TimeHelperTest. Then you can either go to the Test menu, select Run, and finally select Test In Current Context or accomplish the same thing using the keyboard shortcut CTRL+R, T. Look at Figure 3-29 for a reference.



FIGURE 3-29 Test execution menu

9. Performing this action executes only your three tests. You should see the Test Results window (shown in Figure 3-30) appear at the bottom of your editor with the test results.



FIGURE 3-30 Test Results window for your newly created tests

More Info Depending on what you select, you might have a different behavior when you choose the Tests In Current Context option. For instance, if you select a test method like ZeroReturnsSlash, you'll execute only this test case. However, if you click outside the test class, you could end up executing every test case, which is the equivalent of choosing All Tests In Solution.

New Threads Window

The emegence of computers with multiple cores and the fact that language features give developers many tools to take advantage of those cores creates a new problem: the difficulty of debugging concurrency in applications. The new Threads window enables you, the developer, to pause threads and search the calling stack to see artifacts similar to those you see when using the famous SysInternals Process Monitor (http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx). You can display the Threads window by going to Debug and selecting Windows And Threads while debugging an application. Take a look at Figure 3-31 to see the Threads window as it appears while debugging Plan My Night.



FIGURE 3-31 Displaying the Threads window while debugging Plan My Night

The Threads window allows you to freeze threads and then thaw them whenever you are ready to let them continue. It can be really useful when you are trying to isolate particular effects. You can debug both managed code and unmanaged code. If your application uses thread, you'll definitely love this new feature of the debugger in Visual Studio 2010.

Visual Studio 2003 In Visual Studio 2003, the Thread window was rudimentary. It enabled you to suspend or switch to a thread. It was tough to know more about those threads because you didn't have any more information from within Visual Studio 2003. There was no filtering, call-stack searching and expansion, and grouping. The columns were in a fixed order. Back then, the notion of multiple cores existed but wasn't as much in use as it is today. Furthermore, developing for multicore CPUs wasn't facilitated by the .NET Framework in any way like it is today with .NET 4.0 and libraries like PLINQ.

Summary

In this chapter, you learned how to manage your debugging sessions by using new breakpoint enhancements and employing new data-inspection and data-visualization techniques.You also learned how to use the new minidump debugger and tools to help you solve real customer problems from the field. The chapter also showed you how to raise the quality of your code by writing unit tests and how Visual Studio 2010 Professional can help you do this. Multicore machines are now the norm, and so are multithreaded applications. Therefore, the fact that Visual Studio 2010 Professional has specific debugger tools for finding issues in multithreaded applications is great news.

Finally, throughout this chapter you also saw how Visual Studio 2010 Professional has raised the bar in terms of debugging applications and has given professional developers the tools to debug today's feature-rich experiences. You saw that it is a clear improvement over what was available in Visual Studio 2003. The exercises in this chapter scratched the surface of how you'll save time and money by moving to this new debugging environment and showed that Visual Studio 2010 is more than a small iteration in the evolution of Visual Studio. It represents a huge leap in productivity for developers. The gap between Visual Studio 2003 and Visual Studio 2010 in terms of debugging is less severe than in earlier versions. The quantity of information provided by the debugger, the way to visualize the information, and the ease of use and configuration of the projects are the biggest changes that help you be more productive. You'll also see in the next chapter how easy it is to deploy Web applications, their databases, IIS settings, and all of their configurations.

The various versions of Visual Studio 2010 give you a great list of improvements related to the debugger and testing. My personal favorites are IntelliTrace-http://msdn.microsoft.com/en-us/library/dd264915(VS.100).aspx-which is available only in Visual Studio 2010 Ultimate and Microsoft Test Manager.IntelliTrace enables test teams to have much better experiences using Visual Studio 2010 and Visual Studio 2010 Team Foundation Server-http://msdn.microsoft.com/en-us/library/bb385901(VS.100).aspx.