Debug .NET Framework Source Code in Visual Studio 2012?

Question

I am using Visual Studio 2012. I want to Debug .NET Framework source code. I have tried nearly all the options but I am still getting There is source code available for Current Location. Symbols are loaded successfully. I have tried loading Microsoft Symbol Server and tried this url http://referencesource.microsoft.com/symbols. But I am still unable to DEBUG. I have tried these links, http://blogs.msdn.com/b/sburke/archive/2008/01/16/configuring-visual-studio-to-debug-net-framework-source-code.aspx and http://msdn.microsoft.com/en-us/library/cc667410.aspx

Also followed this, http://blogs.msdn.com/b/dotnet/archive/2012/08/15/announcing-the-release-of-net-framework-4-5-rtm-product-and-source-code.aspx

Is anyone able to DEBUG .NET Framework source in VS 2012?

Answer 1

Debugging .NET Framework sources was broken for a long time. See the relevant suggestion on VisualStudio UserVoice Allow developers to step through .NET Framework sources. Good news: it was finally been fixed! See the following blog post from Microsoft:

A new look for .NET Reference Source

In short:

• New web interface for browsing sources: http://referencesource-beta.microsoft.com/
• All sources, including project files, can be downloaded directly: http://referencesource-beta.microsoft.com/download.html (not compilable though)
• There's a new extension for F12 navigation: http://visualstudiogallery.msdn.microsoft.com/f89b27c5-7d7b-4059-adde-7ccc709fa86e
• Sources are always up to date and debugging isn't broken by patches and updates.

It's currently "beta". Eventually it's going to replace http://referencesource.microsoft.com/. Microsoft also promises to add sources of more assemblies.

Answer 2

This feature was broken in VS2010 SP1, it might be broken in VS2012 as well. Or Microsoft might release incorrect PDB files for the latest .NET Framework version (this had happened before). Try alternative solutions. I'm using .NET Reflector VSPro - it allows to decompile assemblies, load decompiled symbols during debugging and use full debugging features for these decompiled assemblies.

Answer 3

In VS 2008 I was able to debug .Net source, but in VS2012 I've got .NET Reflector (VS extension) installed, so it automatically decompiles and allows to debug any .Net code.

Another open source tool is ilspy.net , it saves the decompiled assembly as C# project and you can use the debugging tools.

There are also debugging tools for Windows, that come as part of SDK, but i haven't tried those: http://msdn.microsoft.com/en-us/windows/hardware/gg463009.aspx

Answer 4

Here is a nice post describing how to configure VS symbol server and dotPeek 1.2 to debug decompiled code from VisualStudio: http://blog.jetbrains.com/dotnet/2014/04/09/introducing-dotpeek-1-2-early-access-program If debugging framework or other compiled code is your daily routine I would recommend to reconstruct solution from set of assemblies you use that will save time on symbols loading during debugger attach.

Answer 5

1) PDB files are not up to date. Try to uncheck Tool->Options->Debugging->General->"Require source files to exactly match the original version"

2) You've referenced another of your projects byadding it's dll to your references instead of adding the project as reference. Try to remove the reference add add a new reference to the project from the "Projects" tab

And you can search Google .It's giving more than answers

Answer 6

I've had much luck in the past following the procedure as adviced by SymbolSource.

If you combine this with Resharper, you'll be able to CTRL-click your way through the framework.

There's a long history however of MS not publishing the code of all versions of their binaries. That's why often debugging won't work.

Still, Resharper seems a bit more flexible in downloading source code, and if it can't, it'll give you the disassembled source code, yet undebuggable. Note that JetBrains considers the debugging of decompiled sources a critical feature for dotPeek (the decompiler that comes with Re#), so it might be possible within a not too distant future.