Apart from commonly being free-as-in-beer, open-source is also great because it enables us geeks to have a deep look into the inner-workings of software that we use. How many times have you wondered why a program fails, only to find that it has no logging capabilities, or produces useless output? Open-source often lets you avoid banging your head on the wall too hard, because you can always have a look at the code and try to figure out what the problem is.

But what if the reason still remains a mystery after reading the code? Fortunately then you have the most powerful tool in your development toolbox still left – the debugger. Let’s recap what it usually takes to start debugging third-party code?

Libraries

1. Figure out the branch and tag. If you’re lucky, the owners maintain a great source repository. If you’re not, it’s plain sorcery.
2. Get the code. SVN, Git, Mercurial – piece of cake.
3. Figure out the build system. MSBuild, NAnt, Rake, missing Visual Studio extensions – starting to get a headache.
4. Rebuild the library. Usually straightforward after step 3.
5. Replace library in the actual application. Often hard, especially when the build script failed to produce a matching version number or there was no signing key.
6. Rebuild application with replaced library. To work around missing signatures or mismatched version numbers.
7. Now you have all the binaries, PDBs and sources to dive deep into happy debugging.

Plugins

A plugin is essentially a library, so the steps are similar, but replacing it is much, much easier. Usually it’s just a matter of dropping it into to the right folder.

Applications

We’ve already covered getting and building the source. Replacing applications with your debug-enabled copies might, however, prove especially problematic. What if the application is installed in a location requiring elevation to overwrite? What if it’s part of a production deployment, or consists of many moving parts that would need to be replaced simultaneously?

Fortunately, we can avoid all this with a symbol and source server like SymbolSource, which will provide all the needed PDB files and sources on-demand, when you start a debugging session – regardless if the debugee is a library, a plugin or an entire application. Just configure Visual Studio in a few simple steps.

Personally I’m really happy that so many people publish to SymbolSource nowadays. It’s really easy, and most of the time requires close to no additional work when releasing a library to NuGet. Have a look at these posts to see how easy it is:

• The easy way to publish NuGet packages with sources by David Ebbo,
• The new integrated NuGet workflow by yours truly,
• Why everyone should be using a symbol server by Xavier Decoster.

If you missed it, you can also apply this to private MyGet feeds and be sure your symbols and sources are secured:

• Publishing symbol packages for a MyGet feed by Maarten Balliauw,
• How SymbolSource integrates with NuGet and MyGet and ASP.NET Web Stack nightlies now also on SymbolSource by yours truly.

By pushing symbols and sources to SymbolSource you’ll help all your users avoid the pain of rebuilding code as detailed above.

We’re really proud at SymbolSource that this has caught on! So there was and will be no Part 1 of the series, as there is enough information and adoption on the web already 🙂

Debuggable plugins

Staying in the NuGet universe, there is a tool – NuGet Package Explorer – that has a really cool way of distributing plugins – well… umm… NuGet.  There is a special MyGet feed where anyone is welcome to push plugin packages to, and NPE uses it to provide a list of plugins to its users, download selected plugins to a local cache, and then load all MEF exports from included assemblies.

Creating an NPE plugin is as easy as following these steps:

1. How to: Write plugins for NuGet Package Explorer by Luan Nguyen,
2. nuget.exe pack MyPlugin.csproj
3. nuget.exe push MyPlugin.nupkg -source http://www.myget.org/F/npe

All you need to do let users debug an NPE plugin is to change those steps to:

2. nuget.exe pack MyPlugin.csproj -symbols
3. nuget.exe push MyPlugin.nupkg -source http://www.myget.org/F/npe
4. nuget.exe push MyPlugin.symbols.nupkg -source http://nuget.gw.symbolsource.org/MyGet/npe

You can try the result yourself with our SymbolSource plugin that has symbols published already:

1. Install NuGet Package Explorer from CodePlex if you don’t have it yet.
2. Install our SymbolSource plugin in NuGet Package Explorer.
   
3. Open any package. If there’s nothing named Any on the NuGet feed, you can try one of the ASP.NET Web Stack Nightlies from http://www.myget.org/F/aspnetwebstacknightly.
4. Run Tools -> Analyze package. Our plugin provides additional package validation rules, which are very useful when creating your own symbol packages. In this case it will just warn you that it cannot verify the package filename, because it was opened from a feed.
5. Now rename System.Web.Mvc.xml to System.Web.Mvc.pdb to trick our plugin into loading a malformed symbols file, which we did not anticipate in our code.
6. Run Tools -> Analyze package again to crash the app. Select Debug the program and New instance of Microsoft Visual Studio to launch a debugging session.
7. You should now see Visual Studio detailing a NullReferenceException without any source code to back it up.
8. If you haven’t done so yet, configure http://srv.symbolsource.org/pdb/MyGet as one of your symbol servers at Tools -> Options -> Debugging -> Symbols.
9. Open Debug -> Windows -> Modules and make sure SymbolSource.Integration.NuGet.PackageExplorer.dll has symbols loaded. Right-click on its row and select Load Symbols From -> Symbol Path to load them manually.
10. Find SymbolSource.Intergration.NuGet.PackageExplorer.dll on the call stack and double-click to see where our plugin failed.
11. But that’s not the real reason, there’s a lot more methods on the call stack. Explore it by right-clicking those calls and loading symbols. You’ll need to have http://srv.symbolsource.org/pdb/Public configured as a symbol server for this to work, as all the other assemblies are available as packages on the NuGet Gallery and have symbols published to the regular SymbolSource repository, not as part of the MyGet plugin feed.
12. You should be able to see that something went horribly wrong while reading the PDB file’s hash, included in its header. That’s because we have an XML file serving as a corrupted PDB file.

That’s it. In Part 3 I will talk about debuggable applications and how you can publish them with NuGet, Chocolatey and SymbolSource, so stay tuned.

If you know about any other programs that use NuGet to distribute plugins, don’t hesitate to leave a comment. Also, remember that NuGet is just a means of transport for SymbolSource, and you can upload symbols and sources for just about anything, including tools published with ZIP files, MSI packages or regular setup files.

Let’s create not only an open- but also debuggable-source world 🙂