SymbolSource.org

In this short post I would like to invite you to my personal blog, where I will be posting more behind-the-scenes information about SymbolSource, that does not really fit here. It will also be a place for general .NET and related technology posts, basically stuff that interests me personally.

So far, I've written these pieces:

• Embedding an ASP .NET application in a unit test (part 1)
• Embedding an ASP .NET application in a unit test (part 2)
• Writing an automatic debugger in 15 minutes (yes, a debugger!)
• Accessing stack traces with MDbgEngine and PADRE

I hope you'll find my writing interesting and useful, and won't be discouraged by my non-nativeness in English.

We've updated our NuGet Package Explorer plugin. It is built against the unreleased version 2.5, but we really encourage you to try it out, because it is already perfectly stable at this point, and has some nice new features. From now on, we will only support 2.5+, because of its incredibly cool plugin manager that downloads plugins from a NuGet feed.

In the new version of our plugin we added two new warnings about mismatches between the package file name and its contents: it should end with .symbols.nupkg if and only if the package contains symbols and sources.

We also have a completely new feature that allows you to verify the contents of a package against any symbol server (SymbolSource by default). It will tell you if your submission was correct and if it is already available to end-users.

As always, screenshots tell the story best. The UI is hideous, we know, but as I've written before, the plugin is open source, so you are free to improve it: http://github.com/SymbolSource/Integration.NuGet. Thanks :)

We have some very exciting news to announce today. The OpenWrap package gateway has been extended and now supports the entire protocol. Which means that SymbolSource now offers regular OpenWrap package repositories. You can take advantage of SymbolSource and its flexible permission system to store and share wraps, symbols and sources.

Preparing OpenWrap

1. OpenWrap 2.0.2 is required to use our repositories. You can skip this entire section if you already have it.

2. Make sure you have OpenWrap 1.0.2 before upgrading, otherwise bad things may happen:

   o update-wrap openwrap -system

3. Add the official beta repository:

   o add-remote -name beta -href http://wraps.openwrap.org/beta

4. Update OpenWrap in the system repository (or skip -system if you're running from a test project):

   o update-wrap openwrap -system

Configuring repositories

It might be good idea to start up Fiddler at this point to verify that o.exe is contacting remote repositories. It should, but this is all still beta stuff. Also, you will need an account on SymbolSource to complete some of the steps, so go ahead and register now, if you don't have one yet. From now on %login% will be, you guessed it, your login, and %key% will be your Visual Studio access key.

1. Add the public OpenWrap repository:

   o add-remote -name public -href http://openwrap.gw.symbolsource.org/Public/OpenWrap

2. Go to Metadata and create a private repository for upload testing. 'OpenWrap' is a nice name. Also make note of our Visual Studio key while you're there, it will be used as the password for authentication.

3. Register the private repository with your install of OpenWrap:

   o add-remote -name private -href http://openwrap.gw.symbolsource.org/Public/Private.%login%.OpenWrap -user %login% -pwd %key%

4. Try listing packages (o.exe should access index.wraplist from both locations, plus wraps.openwrap.org):

   o list-wrap -remote

5. If everything goes fine, you'll see a package from the public repository:

   - symbolsource-repositorytest (available: 0.0.1.84582059)

Using the repositories

1. Go to a new directory and initialize a new wrap:

   o init-wrap

2. Now you can add the test library from SymbolSource:

   o add-wrap symbolsource-repositorytest

Uploading your packages

1. Take a package from somewhere or just build your test wrap:

   o build-wrap

2. Publish package to SymbolSource:

   o publish-wrap -path test-1.0.wrap -remote private

3. Verify that the package was uploaded:

   o list-wrap -remote

Symbol package support

With a SymbolSource repository for OpenWrap you also get the entire on-demand debugging experience. Just make sure, before uploading, that your package contains PDB files in bin-* folders and all the sources you used to build the package from in an src folder - you will need to add those files manually (with a ZIP tool) for now. The package will be then processed on the SymbolSource servers. The version for download will be stripped from these files, but they will be available on-demand for Visual Studio. Once OpenWrap gets flavor support, these files will be included automatically during o build-wrap.

Hosting official packages

If you wish to maintain official packages for your project in the main OpenWrap repository at SymbolSource, please let us know through the usual channels (Google Group, Twitter) and we'll assign the required permissions to your account ASAP.

There is a whole range of exciting possibilities arrising from having a catalogued repository of eleased code like SymbolSource. We have been experimenting with various ideas for some time now. Today we would like to announce the first step in providing a dynamic, relfector-like view of all source code on SymbolSource.

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.