Our pre-release versions were already in an excellent shape so we didn’t have to change much. In fact, there are no surface area changes and no behavioral changes. We updated a few strings to align with some branding changes (in case you didn’t notice: “Metro style apps” are now called “Windows Store apps”).
However, we added one feature we believe is worth discussing in more detail: we now provide a symbol package for MEF.
What are symbol packages?
If you read our .NET 4.5 release announcement carefully, you noticed that we also updated the reference source that allows you to debug the source code of the .NET Framework. Scott Guthrie discussed this in detail here. For out-of-band releases we thought it doesn’t make much sense to publish our source as part of the .NET Framework reference sources drop because one of the goals of releasing out-of-band is being able to publish more frequently than the .NET Framework itself.
Instead, we decided to take advantage of NuGet’s symbol packages. In a nutshell, symbol packages allow Visual Studio to find .pdbs and sources for a given binary.
So let’s have a look at how debugging MEF with the NuGet symbol package would look like.
Imagine you want to understand what MEF does when you call ContainerConfiguration.WithAssemblies. Without a symbol package, you would need to download the MEF sources from CodePlex and build it yourself. However, since we don’t publically release the keys we use to build MEF, the resulting assemblies will have a different identity than the ones we ship on NuGet. So depending on how big your app is changing the references can be quite cumbersome.
With symbol packages all you need to do is configure VS once so that it is able to automatically find the correct .pdb files and sources for the binaries we published on NuGet. After that, all you need to do is set a break point in your app:
and hit F11. And voila, you end up in MEF’s source code!
Visual Studio 2012 RC Users: Apparently, this feature doesn’t work on RC but since we published RTM, there shouldn’t be a reason to use RC anymore, should there?
Why does this not work for TPL Dataflow?
Unfortunately, we didn’t have enough leeway to cut through the red tape in order to be able to publish the source code of TPL Dataflow. Although I can’t promise anything one could at least imagine us getting permission to publish reference sources without actually open sourcing it.
How to configure Visual Studio
As mentioned earlier, you need to setup VS in order to use NuGet symbol packages. By the way: none of this stuff is specific to MEF – once you configured VS this will work for all NuGet packages that have corresponding symbol packages.
The first thing you need to do is adding NuGet’s symbol server to the list of locations Visual Studio uses to probe for your .pdb files. Go to Tools -> Options -> Debugging -> Symbols. Create a new entry and paste in http://srv.symbolsource.org/pdb/Public:
In order for Visual Studio to show stack frames from code not written by you, you need to disable the “Just My Code” feature. Also, in order to enable downloading the source files you also need to check “Enable source server support”: