NET Debugging : Visual Studio (part 2) - .NET Framework Source-Level Debugging

2. .NET Framework Source-Level Debugging

Any given .NET application typically utilizes a number of different types defined in the .NET frameworks. Types can range from simple data types to complex Web service bindings, and abstracts much of the underlying complexity associated with using the technology directly. As with any abstraction though, the situation gets a little hairy if you get stuck and need to debug a problematic application. Rather than having to attempt to reverse engineer the abstraction to get clues as to why the application may be failing, it is much easier if source code is available to look at or even better if source code is available to debug with! Luckily, Microsoft recognized this need and published the source code for parts of the .NET framework. The really great thing about this is that not only is the source code available, but it can also be integrated into Visual Studio so that the source-level debugging that all developers have come to expect also works with the published .NET framework source code. Here, we will take a look at what it takes to configure Visual Studio for seamless .NET framework source-level debugging.

Visual Studio Hot Fix

To use the integrated .NET framework source code with Visual Studio, the hot fix located at https://connect.microsoft.com/VisualStudio/Downloads/DownloadDetails.aspx?DownloadID=10443&wa=wsignin1.0 must first be installed.

For source-level debugging to work, the Visual Studio debugger must be told where it can find the source code for the module that is being debugged. Where does it get this information from? It gets it from the corresponding symbol files that are also made publicly available. Much in the same way that Microsoft publishes all public symbols for other available products on the public Microsoft symbol server, so is the case for the .NET framework. The biggest difference, however, is how much information is exposed in the symbol files being exposed. The symbols made available on the public symbol server are “stripped,” meaning that certain information (including source-level information) has been removed from the symbol file. In contrast, the symbols made available for the .NET framework binaries have full debug information including source-level access, which Visual Studio uses to then find the source code published on the Internet. The first step is to tell Visual Studio that we plan on using a source server to access source code during our debug sessions. This can be enabled by selecting the Tools, Options, Debugging, General menu, which brings up the dialog shown in Figure 6.

Figure 6. Enabling source-level debugging

In the Debugging, General page, please uncheck the Enable Just My Code (Managed only) checkbox and check the Enable source server support checkbox.

Next, we navigate to the Symbols page (in the same Options page) to specify the location of the symbol server we want to use, as shown in Figure 7.

Figure 7. Setting the symbol server

In the symbol file locations, we add the following URL, which contains .NET framework symbols: http://referencesource.microsoft.com/symbols. Additionally, we tell Visual Studio that we would like to cache all downloaded symbol files in the folder C:\Zone. The caching mechanism can be a time saver to avoid downloading the same symbol’s files each time a debug session is started. Finally, we tell Visual Studio that we want the locations to be used only when the symbols are manually loaded—that is, all the configuration that is needed for Visual Studio to support source-level debugging of the .NET frameworks. Let’s give it a shot and see how easy it is. Create a simple C# console application with the following line of code in the Main method:

Console.WriteLine("Let's use SOS!");

Build the project and set a breakpoint on the preceding line of code using F9. Next, press F5 to debug the application; after the breakpoint hits, bring up the Modules window using CTRL-ALT-U. Locate the mscorlib.dll module and right-click it followed by Load Symbols. This downloads the symbols for the mscorlib.dll module that will enable source-level debugging. When the symbol has finished downloading, the Symbol Status column shows Symbols Loaded. Now, we can step into the Console.WriteLine code by pressing F11. The first thing you will notice is that an End User License Agreement (EULA) is displayed, as shown in Figure 8.

Figure 8. .NET Framework source EULA

Please take your time reading through the EULA and, if you agree to the terms, click the Accept button. The source code behind the Console.WriteLine method is now automatically downloaded and shown in the debugger, allowing you to step through the code just like you would your own code.

Please note that, at the moment, the following symbols are made available on the symbol server:

• mscorlib.dll

• system.dll

• system.data.dll

• system.drawing.dll

• system.web.dll

• system.web.extensions.dll

• system.windows.forms.dll

• system.xml.dll

• Windows Presentation Foundation DLL’s

• Microsoft.visualbasic.dll

Microsoft has made sure that the infrastructure behind publishing new symbols and source code is fully automatic, and we can expect to see more and more symbols and source code become available with time.