February 27, 2021
Hot Topics:

Framework Source Code Stepping

  • By Nick Wienholt
  • Send Email »
  • More Articles »

.NET Source Code Debugging

Unlike MFC, ATL, and the CRT, which have had the library source code available since the earliest days of Visual C++, the source code for the .NET Framework Libraries has not been available generally until now. An earlier effort to address the unavailability of the .NET Framework Library source code was the Shared Source CLI (Common Language Infrastructure) project, commonly referred to by its code-name of Rotor. Rotor, which is available in both a .NET 1.x and 2.0 version, is a stripped down version of the .NET runtime and Framework Libraries that contains a great deal of commonality with the commercial .NET releases. Unfortunately for Managed Extension and C++/CLI developers, the only compilers included with Rotor are a C# and JScript compiler.

To widen the audience and simplify the process of stepping into the .NET source code, Microsoft announced the release of the source code for the Framework Libraries in late 2007. The recently released Visual Studio 2008 SP1 makes stepping into the .NET source code extremely simple—a single setting on the Debugging | General options page configures all the required settings to allow Visual Studio to download the relevant debug symbol files and source code, as shown in Figure 5.

Click here for a larger image.

Figure 5: Visual Studio 2008 SP1 .NET Source Code Stepping

As of late August 2008, the debug symbol files for .NET Framework 3.5 SP1 were available, but the corresponding source code was not available. Visual Studio 2008 SP1 will attempt to download the source code file, but the error message shown in Figure 6 will be displayed in the Output Window.

Click here for a larger image.

Figure 6: Source Server Error Messages

For Visual Studio 2008 without SP1, the first step for Framework source code stepping is applying a Visual Studio 2008 QFE. After the QFE has been applied, Enable source Server support needs to be checked, as shown in Figure 5. The final step is to place an entry for the .NET Framework Source Symbol server (http://referencesource.microsoft.com/symbols) in the Debugging | Symbols settings before the setting for the standard Microsoft symbol server. The reason that the .NET Framework DLLs need a special symbol server is the same as the reason for the MFC and ATL debug symbols—the standard symbol server has debug symbol files with the source information stripped out. Figure 7 shows the final Debug Symbol settings.

Click here for a larger image.

Figure 7: Visual Studio Symbols for ATL/MFC and .NET Source Debugging

Once these settings have been set up correctly, it will be possible to step into .NET code in the same manner as ATL and MFC code. If the check-box Search the above locations only when symbols are loaded manually on the Symbols setting dialog is checked, Visual Studio will not load the .NET Framework symbols automatically, and the context menu of the Module debug window or the Call Stack debug window will need to be used to load the symbols manually. This will give a faster start to debug sessions, but the draw back is the need to go through each DLL manually and load the symbols when they are needed. If the Framework source code is being stepped into frequently, clearing the checkbox is recommended.

If all the settings have been applied correctly, stepping into the Framework source code is a simple matter of pressing F11 at the appropriate breakpoint. Figure 8 shows the results of successfully stepping into the Console class.

Click here for a larger image.

Figure 8: .NET Framework Source Code Stepping

Page 2 of 3

This article was originally published on September 8, 2008

Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date