A first hand look from the .NET engineering teams
This post was written by Alok Shriram, Program Manager on the .NET Framework team. He will show you a significantly improved experience around .NET Reference Source.
Today I'm very excited to announce that we have an awesome new experience to use the .NET Framework reference source.
First of all, most people just want to look at code. So we've added a brand new source browsing experience. For a tutorial, checkout our Channel 9 video:
This new browsing experience provides the following features:
We generated this site using Project Roslyn, our new C# and VB compilers.
Using .NET Reference Source for debugging
We are also happy to announce that you can now step through .NET framework sources for .NET framework 4.5.1 and any associated patches and updates.
This has been one of the highest voted items on User Voice:
We are pleased to close this item as resolved. To read about how to setup VS to take advantage of this feature please go here.
So what does it mean for your day-to-day activities? Let’s assume that you have an app that uses List<string> to display a set of controls. One day after a framework update you suddenly realize that the order of the controls in your app has suddenly changed. You fire up VS and follow the instructions described above and start stepping through you code like you normally would. You get to the point where you were doing your sorting:
Hit F11 and voila you are in the List<T>.Sort code! Sweet.
We find that this is an extremely useful diagnostic tool for our developers when they are investigating issues internally. So we decided to fix this experience so that it also "just works" for you. This will give you the ability to better understand and diagnose issues between our and your code.
Historically since the inception of this effort, we have published sources and PDBs for every major .NET framework update namely .NET framework 4.0 and 4.5. However these builds would be rendered effectively useless the moment any update to the framework was released, since the binaries on the updated box no longer matched the PDBs that were indexed on the reference source server. Unfortunately the design of the system that we had in place was geared towards doing single and infrequent pushes of sources and symbols out and did not account for the sheer volume of builds and patches that come are produced out of the .NET framework build system.
Starting with .NET 4.5.1 we have radically changed the symbol indexing and publishing process to be in sync with the build process such that as and when updates are shipped , the corresponding PDBs are also updated to the reference source site appropriately. The summary of this is going forward the reference source debugging experience should just work. If it does not use the troubleshooting instructions at the link provided above and send us an email with the data requested, we will do our best to turn it around quickly.
There is one caveat to this experiences; for security updates or updates that are otherwise deemed to have changes that we do not want leaked (think security exploits) you will still have a debugging experience, but rather than the file that corresponds to that PDB, you will get the last broadly shipped copy of that file. This could manifest itself in a slightly skewed debugging experience if you are stepping through a file where the fix was made.
The Microsoft Symbol Server is a repository where all public PDBs generated by most teams at Microsoft end up. However all PDBs that are present here do not have any source information in them, which makes them not very useful for stepping through sources. When you are trying to debug .NET Framework source please ensure that you do not have the Microsoft Symbol Server enabled. Doing so could result in the symbols being loaded from the Microsoft Symbol Server and the source stepping experience would not work in that case. You can disable Microsoft Symbol Server lookup via Tools | Options | Debugging | Symbols. Ensure that the checkbox in front of Microsoft Symbol Server is unchecked.
But wait! There is more:
Replacing referencesource.microsoft.com. Our most immediate goal is to retire the current page at http://referencesource.microsoft.com in favor of the new browsing experience. Please take a look at the old site and let us know of any concerns you have around deprecating it.
Updating the indexed sources. The version of the framework that we currently have indexed is .NET Framework 4.5.1. Due to the improvements we made in our engineering system, we're now able to update both the symbols and the sources as new versions of the framework are released.
Adding source for assemblies. As you can probably notice, the set of assemblies that we have is not complete. We don't intend to keep it that way, so we plan to expand the set of assemblies over time.
Today we announced a new browsing experience for the .NET Reference Source. We've also fixed the long standing issue with using reference source for debugging.
We would love to hear your feedback. Please let us know what you think about the new browsing experience by leaving a comment on this blog or by emailing us. Also, if you're missing specific assemblies, please let us know so that we can prioritize which ones we add first.
Happy browsing & debugging!
Are there any plans to make reference source for the native code parts of .NET available?
For me, insight into the implementation of the framework hosting interfaces in mscoree.dll would be extremely valuable.
I agree with @Govert, we do have the 2.0 CLR source (Govert if you did not know about it Google "Shared Source Common Language Infrastructure 2.0 Release ") but it would be nice to have the same thing for CLR 4.
Thanks so much for this.
As a suggestion it would be extremely useful to have some sort of tool that would tell whether a local DLL has a related PDB on the source server. So extract the GUID for the PDB GUID from the DLL and simply state whether there is a matching one on the source server.
Ideally what I would really like is to be able to point to an EXE or DLL and find out which of the .NET DLL's it depends on have matching PDBs and are hence debuggable.
Maybe this already exists but I haven't been able to find it on my searches.
One issue I encountered when I want to point someone else to a specific line of code in Reference Source. It seems that I cannot add a hyperlink with line number in Outlook or Word.
After I edit the hyper link, say, referencesource.microsoft.com, if I edit it again, the last anchor is removed automatically and it becomes referencesource.microsoft.com.
@Govert @Scott as of right now we were not planning on releasing the native parts of .NET. Since this seems to be of interest to folks, we can start a conversation about this on the team.
Try removing the first hash and appending .html after .cs:
This is awesome news. Now... add in the XAML files and things will get even better. :)
The link old site in "What's Next" and " new browsing experience for the .NET Reference Source" in Summary point to same site. I think the old site was "referencesource.microsoft.com/symbols".
Am i missing something here?
awesome, Great Work!!! very nice
I am getting a 404 error on every symbol the debugger tries to download.
Is this because I have taken all the security patches
@cj could you touch base with us with the information we have requested in the trouble shooting section on the site refsource.redmond.corp.microsoft.com/setup.html.
I'm still a bit confused. In a previous post (blogs.msdn.com/.../announcing-the-release-of-net-framework-4-5-rtm-product-and-source-code.aspx) it is mentioned that I need to add a new symbol server (referencesource.microsoft.com/symbols).
Is this still required for your new source debugging implementation for .NET 4.5.1 and VS2013? Or is it sufficient to leave "Microsoft Symbol Servers" checked?
Additionally, if I am targeting .NET 4.5 while 4.5.1 is installed - do I need to add referencesource.microsoft.com/symbols as a symbol server or should I leave "Microsoft Symbol Servers" checked?
Could you please clarify this on referencesource.microsoft.com/setup.html
where is the .net 4.0 source code package?
Please, please add the WPF default themes to reference sources
(especially since they are not accessible anymore via go.microsoft.com/fwlink or code.msdn.microsoft.com/.../FileDownload.aspx)
Aside from this, thanks so much for this service!