Creating a symbol package can be challenging the first time, especially when you're trying to do it manually or in your own build script, without using the nuget.exe pack -symbols command. Fortunately NuGet Package Explorer 2.0 has a great new feature: package analysis. It runs various rules to verify package correctness and best practices. These rules can also be provided through plugins, so we wrote our own to provide validation rules for symbol packages.

Today we are proud to present the long waited support for private symbol and source repositories. It will allow you to benefit from the ease of debugging that SymbolSource provides without publicly disclosing any part of you code. Symbols and sources will only be fetched through the authenticated Visual Studio URLs and only after verifying permissions defined on the SymbolSource website.

Those of you who follow me on Twitter (@TripleEmcoder) will already now this, but I'd like to share a few more details in this post: we've implemented an automated end-to-end test and scheduled it to run every hour. If anything goes wrong we'll be able to detect and fix it much faster than before.

Before you get discouraged by this long (although we feel needed) introduction, please know that we are introducing a feature to delete packages from SymbolSource. Well, sort of.

When we were initially designing SymbolSource, we didn't believe there was much need for deleting symbols and sources once they were published. The reasoning behind this is that when you build up the expectation that symbols of all the libraries that you use can be easily loaded on-demand and that it's possible to likewise step into all of their sources, everything should be done to avoid breaking that expectation. It's a matter of trust. If you see a project name mentioned on the site, you should expect all its symbols to be available.

Although with the release of NuGet integration uploading symbols and sources to SymbolSource became a matter of simply invoking one command, it is still possible to mix up packages and end up uploading binaries and symbols that do not match. SymbolSource will of course verify the integrity of an incoming package, but there is no way for it to stop you from uploading a package to nuget.org with different binaries.

This post will show you how to quickly verify that symbols can be downloaded for a given set of binaries.

So far there have mostly been instructions on creating local or remote-but-read-only NuGet feeds. You can read about it in a few places, like these:

• NuGet documentation - Hosting Your Own NuGet Feeds
• Phil Haack's blog - Hosting a Simple “Read-Only” NuGet Package Feed on the Web

This method, although very simple, unfortunately has a big drawback: you can't publish packages with nuget.exe, so none of the new SymbolSource integration goodness will be available to you.

But since the sources of all components that drive the NuGet website and package feed can be downloaded from Codeplex, you can set up the exact same experience with a separate, private data store.

After a short false start of this note that hopefully none of you actually saw, here is the full announcement post.

For the past few weeks we have been working hard together with the NuGet team on simplifying the symbol and source distribution story for .NET libraries.

What we can finally show you today is an integrated workflow that allows effortless submission of packages to both NuGet and SymbolSource sites simultaneously.

If you're new to the subject, have a look at Cameron Skinner's blog for a series of nicely illustrated posts on the topic of debugging, symbols and symbol/source servers:

• Debugging Series: Symbol Server
• Debugging Series: Symbols Server and Your Symbols

This is a a recommended read for anyone interested in configuring a proper debugging experience, including Microsoft Reference Source server and SymbolSource.

As NuGet 1.2 has been released recently it would seem appropriate to write something new on the blog here, so that at least the previous note gets pushed down. For now let me just say, that we are very busy working on tighter integration with NuGet and a unified workflow for publishing packages simultaneously to nuget.org and symbolsource.org. We should be ready to announce it soon, so please stay tuned.

Congratulations to the NuGet team for releasing 1.1! However, there are at least two reasons why we are really looking forward to using the next version, 1.2.

Framework Profile Support

NuGet 1.2 will bring an important bugfix and new feature regarding framework folder naming. The pattern will be extended to include a framework profile in the following way:

{framework}{version}-{profile}

That means that net35-client and net40-client will become legal and fully supported.You can have a look at preliminary documentation for this new feature on the wiki page: Framework Profile Support.

At the same time a bug was fixed that prevented libraries in nested folders to be detected and referenced correctly. Now all files for the appropriate framework will be added recursively. You can see the original issue here: #664 - Incorrect mapping of lib/* to FrameworkName.

Symbol Server Support

The NuGet team is also looking at a way of simplifying package uploading to SymbolSource. You can vote for this issue here: #661 - Simplify Integration with a Symbol Server.

This is strongly related to automatic package building, which you can have a look here (prototype screencast included): #675 - Streamlined Workflow for creating packages.