Blog | SymbolSource.org - Your source for debugging symbols... and sources.

More on SymbolSource and related technologies

Sun, 11 Dec 2011 16:32:39 +0200

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:

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

Updated NuGet Package Explorer Plugin

Tue, 15 Nov 2011 17:11:20 +0200

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 :)

Using SymbolSource as an OpenWrap repository

Sat, 08 Oct 2011 12:17:55 +0200

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

OpenWrap 2.0.2 is required to use our repositories. You can skip this entire section if you already have it.
Make sure you have OpenWrap 1.0.2 before upgrading, otherwise bad things may happen:

o update-wrap openwrap -system
Add the official beta repository:

o add-remote -name beta -href http://wraps.openwrap.org/beta
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.

Add the public OpenWrap repository:

o add-remote -name public -href http://openwrap.gw.symbolsource.org/Public/OpenWrap
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.
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%
Try listing packages (o.exe should access index.wraplist from both locations, plus wraps.openwrap.org):

o list-wrap -remote
If everything goes fine, you'll see a package from the public repository:

- symbolsource-repositorytest (available: 0.0.1.84582059)

Using the repositories

Go to a new directory and initialize a new wrap:

o init-wrap
Now you can add the test library from SymbolSource:

o add-wrap symbolsource-repositorytest

Uploading your packages

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

o build-wrap
Publish package to SymbolSource:

o publish-wrap -path test-1.0.wrap -remote private
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.

Online source code navigation

Wed, 05 Oct 2011 16:30:27 +0200

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.

Source element tree

To see the first piece of new functionality, have a look at HtmlAgilityPack.dll. Here you can see all of the code elements (namespaces, classes, methods etc.) displayed in a hierarchy. Clicking on any element will load the file where it was declared. If an element spans multiple files (like a namespace), you'll be asked to pick a file from a popup list.

What's next

There are a couple of things we'd like to do at some point, some reflector-like, but also many only achievable with SymbolSource:

have the tree jump and highlight chosen elements in the source file view,
make actual source fragments (names of types, methods, etc.) clickable,
display help popups based on XML comments,
generate lists of changes between project releases,
calculate code metrics,
visualize project dependencies, both explicit and implicit.

As always, we'll be glad to get your input! Share your thought on our Google Group.

Package validation in NuGet Package Explorer

Wed, 07 Sep 2011 09:02:16 +0200

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.

Features

The current release contains a DLL and PDB viewer that displays binary and symbol hashes, and the list of source files that have been compiled in. There is also a number of validation rules that produce the following:

(warning) Assembly compiled without symbol support
(warning) Missing symbol file for assembly
(warning) Unnecessary symbol file for assembly
(warning) Orphan symbol file found
(error) Mismatched assembly and symbol hashes
(error) Missing source file

Download

SymbolSource.Integration.NuGet.PackageExplorer.dll

Install

You can use one of two ways to install a plugin in NuGet Package Explorer:

Go to Tools -> Plugin Manager -> Add and select the DLL.
Copy the DLL to %LOCALAPPDATA%\NuGet\PackageExplorerPlugins.

Both methods do the exact same thing.

Source

We are releasing this plugin and one of our internal libraries that it requires as open source. Have a look at GitHub if you're interested in how the plugin was implemented or if you would like to contribute to this project:

Announcing private symbol and source repositories

Thu, 25 Aug 2011 15:31:33 +0200

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. For now support for private storage comes in two flavors.

Private repositories

These are additional repositories that you can create automatically during NuGet package upload. Just push to an URL like this:

http://nuget.gw.symbolsource.org/Public/Private.<login>.<name>

You can use whatever <name> that you like, but <login> must match your login on the site, which will be an ugly hash until you associate your NuGet API key on the Authentication page.

Read access will only be possible through this debugging URL:

http://srv.symbolsource.org/pdb/Public/<login>/<hash>

You can also grant other users access to your symbols and sources - as long as you know their login registered with this site. Once you create a private repository permissions can be defined through the Metadata page.

Separate companies

We are also launching an open beta of hosted SymbolSource instances. These instances are internally called companies, and the Public part of URLs you see all over our service is an example of such an entity.

By registering a new company you will get an entirely separate instance of SymbolSource at http://www.symbolsource.org/<company>, which will allow you to define your own set of repositories and users. In the future this will also allow you to integrate authentication and authorization with an external store like Active Directory. For now, you will be able to manage permissions through the administration panel, which exposes the entire flexibility of SymbolSource permissions. Read and write access can be granted on any level of the symbol/source hierarchy: company, repository, project or version.

With a separate company you'll be able to push to any URLs like the following:

http://nuget.gw.symbolsource.org/<company>/<repository>.

And Visual Studio will only be able to download symbols and sources with this URL:

http://srv.symbolsource.org/pdb/<company>/<login>/<hash>

Because we would like to make this feature as robust and easy to use as possible, for now we will personally oversee the provisioning of every company account. Please let us know through any of the usual channels (Google Groups, Twitter or e-mail) if you'd like to take part in the beta program.

SymbolSource health monitoring

Tue, 26 Jul 2011 19:30:49 +0200

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.

The scenario is as follows:

Find the most recent version of the test package on nuget.org.
Create a simple C# project with a few files.
Modify one of those files with a comment stating the next version.
Use nuget.exe pack command to compile the project and build a package (with -symbols to generate a package for SymbolSource).
Upload both packages to nuget.org and symbolsource.org, accordingly.
Download and extract the package from nuget.org into a separate folder.
Run Debugging Tools for Windows (this uses the same components as Visual Studio) to make sure that symbols for the package can be downloaded from symbolsource.org.
Verify that the downloaded PDB file contains refernces to all source files used to build the test library, that they can be downloaded from SymbolSource and that their content has not been corrupted in any way.

There is an interesting thing to note by anyone who uses symbol server support in Debugging Tools for Windows - cdb.exe, symchk.exe or symsrv.dll. If you try to use any of those while running as a service (like we did, running the test scenario in CruiseControl .NET), web requests will not be made using the regular WinINET stack, but WinHTTP. There is an interesting catch with the latter one, having a default bogus HTTP proxy configured. You need to either reconfigure WinHTTP to use your own proxy or disable proxying in the registry. This equals to setting the following keys:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Symbol Server]
"NoInternetProxy"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Symbol Server]
"NoInternetProxy"=dword:00000001

[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Symbol Server]
"NoInternetProxy"=dword:00000001

[HKEY_CURRENT_USER\SOFTWARE\Wow6432Node\Microsoft\Symbol Server]
"NoInternetProxy"=dword:00000001

To experience this behavior in your own account, set this environment variable:

SET DBGHELP_WINHTTP=AnythingOtherThanEmpty

You can test this with the commands described in my previous post on Veryfing symbols after upload to SymbolSource.

For more info on the WinHTTP issue check out these links:

Using symbol server / symsrv from local system account - a discussion on microsoft.public.windbg (sadly I couldn't find archives of this newsgroup anywhere else that would not strip out important parts of messages)
How does cdb access the Microsoft Symbol Server from within a Windows Service - a Facebook note that is actually incredibly technical and useful (I was truly shocked).

Deleting packages from SymbolSource

Mon, 27 Jun 2011 22:00:10 +0200

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. Symbols are quite different than binaries. You may want to have binaries of various versions of your library available for download, and you may want to remove a version altogether, e.g. when if you discover a critical problem with it. But that's only valid for the distribution side of things: be it your website, NuGet or any other channel. By the time that you remove your package from distribution it might already be referenced in countless projects and there is no way to force users to upgrade from the flawed version. Those projects at some point will surely benefit from a symbol/source server. Leaving symbols behind does not cause any harm, it can only be beneficial.

One of the possible reasons to remove a package is to keep versions in sync between SymbolSource.org and a repository like NuGet.org. Imagine that you uploaded a binary package, then discovered and fixed a problem with it and reuploaded it to the repository without changing its version number. There would be nothing wrong with this approach, if the new package contained the exact same binaries - perhaps just more or less of them. There is nothing at NuGet.org, however, that prevents you from uploading completely different binaries for the same package. Also note that good practice of versioning (you might want to take a look at http://www.semver.org for an example) dictates that once you publish a package, you should never ever make modify it - instead bump up the version number and upload again. This has been always supported at SymbolSource.org.

Nevertheless, many of our users requested the feature to delete packages. And there are of course situations when this is appropriate: you might have only uploaded to SymbolSource for testing, so you are sure that the binaries did not leak into the world, or you might really need the version number to stay at some value. That's why from now on you can use nuget.exe to delete packages from SymbolSource.org the same way you can from NuGet.org:

nuget.exe delete MyLibrary 1.0 -source http://nuget.gw.symbolsource.org/Public/NuGet

But since we still believe this is a bad thing to do, a package deleted this way will only really be hidden. It will not be shown anywhere on the site, and you will be able to upload again using the same version number, but symbols will still be served for the hidden package. As its maintainer you will be the only person to see its metadate on the site and you will be able to restore to it to a fully available state, provided that the same version has not been uploaded in the meantime.

A way to pernamently delete all resources that came with a package will be also soon made available.

Please let us know your thoughts on this matter.

Veryfing symbols after upload to SymbolSource

Sat, 14 May 2011 22:58:55 +0200

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.

You will need to set up a few things first:

Download Debugging Tools from the Windows SDK - run the SDK web installer and select Debugging Tools for Windows under Common Utilities to download and install just the bits that you will need.
Prepare two directories - the first one with all the binaries that you will be verifying (e.g. Z:\Binaries) and a second one as a cache for downloaded symbols (e.g. Z:\Symbols).

The binary directory will be searched recursively, so you can extract many packages into separate subdirectories. Make sure there are no PDB files present.
Open a command prompt and add Debuggin Tools to your PATH variable to make things easier:

set PATH=%PATH%;C:\Program Files\Debugging Tools for Windows (x64)

Now you can do the actual verification:

Run symchk.exe on the entire binary directory:

symchk.exe Z:\Binaries /su "SRV*Z:\Symbols*http://srv.symbolsource.org/pdb/Public" /oi /op /r

If everything goes well, this will result in output similar to the following:

SYMCHK: Orchard.Core.dll          PASSED  - PDB: Orchard.Core.pdb          DBG: <N/A>
SYMCHK: Orchard.exe               PASSED  - PDB: Orchard.pdb               DBG: <N/A>
SYMCHK: Orchard.Framework.dll     PASSED  - PDB: Orchard.Framework.pdb     DBG: <N/A>
SYMCHK: Orchard.WarmupStarter.dll PASSED  - PDB: Orchard.WarmupStarter.pdb DBG: <N/A>

SYMCHK: FAILED files = 0
SYMCHK: PASSED + IGNORED files = 4

Most often you will see these two types of errors:

SYMCHK: FluentNHibernate.dll FAILED  - FluentNHibernate.pdb mismatched or not found
SYMCHK: FluentNHibernate.xml IGNORED - Not an executable file (file does not have a DOS header)

When you do come across a failure, it's worth investigating with the following command:

symchk.exe Z:\Binaries\FluentNHibernate.dll /su "SRV*Z:\Symbols*http://srv.symbolsource.org/pdb/Public" /v

In verbose mode symchk.exe will output a lot of information about the symbol loading process, among which will be lines like the following:

DBGHELP: Symbol Search Path: SRV*Z:\Symbols*http://srv.symbolsource.org/pdb/Public
DBGHELP: No header for Z:\Binaries\FluentNHibernate.dll.  Searching for image on disk
DBGHELP: Z:\Binaries\FluentNHibernate.dll - OK
SYMSRV:  Z:\Symbols\FluentNHibernate.pdb\01D37CC489F649B89A1122C482A574CB1\FluentNHibernate.pdb not found
SYMSRV:  http://srv.symbolsource.org/pdb/Public/FluentNHibernate.pdb/01D37CC489F649B89A1122C482A574CB1/FluentNHibernate.pdb not found

This shows clearly that a PDB for the given DLL wasn't found on SymbolSource.

A quick reference to symchk.exe options

The meaning of the symchk.exe switches that were used in the examples is the following:

Switch	meaning
/su	Search the following symbol path and always update.
/r	Scan the directory recursively for binaries.
/oi	Additionally list files that were ignored.
/op	Additionally list files that passed verification.
/op	Verbose mode. Inform about every action taken.

Ideas for improvements

If you have any ideas how this process could be improved, please share them with us. One possibility is to wrap symcheck.exe and nuget.exe into a script that would just take a package name and version and output a yes/no result. Perhaps there are other ways?

Set up your own NuGet gallery with SymbolSource

Fri, 22 Apr 2011 14:36:28 +0200

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. Before we dive into the 8 step instruction that follows, let's establish our goal. Imagine for a moment that you work at the same company that I do, which is called Caliper, and that we have a server called Polaris. At the end of step 8 you should be able work with internal NuGet packages the same way you do with with regular ones:

nuget.exe list -source http://polaris/nuget-server/FeedService.svc
nuget.exe push SecretLibrary.0.1.nupkg 8cd3ad95-19a3-47d3-81af-090280077f24 -source http://polaris/nuget-server
nuget.exe push SecretLibrary.0.1.symbols.nupkg 8cd3ad95-19a3-47d3-81af-090280077f24 -source http://nuget.gw.symbolsource.org/Caliper/NuGet

Of course, you'll be also able to use our clone of the nuget.org site and install and debug packages right from Visual Studio.

Interested? Then let's get going.

Step 1: Getting the sources

There are a few repositories that you will first need to clone with Mercurial:

GalleryServer (https://hg01.codeplex.com/galleryserver) - this is a backend application containing the package feed - both nuget.exe and the frontend site use it to list, download and publish packages.
Orchard.Gallery module (https://hg01.codeplex.com/orchardgallery) - this is an Orchard module that runs the frontend sites - nuget.org (with Packages) and orchardproject.net/gallery (with Modules and Themes).
Orchard (https://hg01.codeplex.com/orchard) - unless you've been on some exotic trip for the past few months (in which case I envy you a lot), you must have heard about Orchard - it's an extensible CMS platform built in .NET, and we'll need it to run the Orchard.Gallery module.
OrchardGallery theme (https://bitbucket.org/kevinkuebler/orchard-gallery-theme) - this is the orchardproject.net/gallery theme, but it's also required for a NuGet gallery.
NugetGallery theme (https://bitbucket.org/bradmi/nuget-gallery-theme) - this is the nuget.org theme built on top of the OrchardGallery theme.

Step 2: Building projects and preparing a site structure

The next step is to build the downloaded sources, but before you do that you need to switch Orchard to the correct revision. This is taken from the Readme.txt file of the Orchard.Gallery module:

The Orchard.Gallery module is currently being developed against the 1.x branch of the Orchard repository, changeset number: 4406 (7caba1cd1dcd).

Being new to Mercurial I had some trouble finding the way to do this, so if you are using TortoiseHg, I suggest having a look at the Update... context menu item. Once you switch to revision 4406 it should look like this:

To build the necessary components:

Run ClickToBuild.bat in GalleryServer.
Run ClickToBuild.cmd in Orchard.
That's it, all the other required modules and themes will be built automatically at run-time by Orchard.

Step 3: Configure IIS to run Orchard

The actual web application that you will be running is in src\Orchard.Web. I named it nuget-gallery and placed it in C:\WebSites\nuget-gallery, so that's what you'll see on the screenshots, but the naming is all up to you.

Before going further, modify Web.config to run Orchard under full trust. Change <trust level="Medium" originUrl="" /> to <trust level="Full" originUrl="" />. This is required by the Orchard.Gallery module.

Now you can run IIS Manager and configure the web application. Right click Default Web Site and select Add Application....

Be sure to select an application pool configured to use ASP.NET 4.0.

Step 4: Run the Orchard site and install required modules

At this point you should be able to access the Orchard site. In my case this was at http://polaris/nuget-gallery. During the first run you can configure the name of you site (I went with Caliper NuGet Gallery, since that's the name of our company) and set a password for the admin user (at least 7 characters). For now I suggest using the default SQL Server Compact Edition option to save on additional work.

Now go to the Dashboard, pick Modules in the side menu and install the following modules (order is important because of compile-time dependencies):

Profile
Taxonomies
Voting
Contrib.Reviews

After that you can add modules and themes downloaded earlier.

Copy the Orchard.Gallery module to C:\WebSites\nuget-gallery\Modules. Note that the name of a module folder is important.
Copy OrchardGallery and NugetGallery themes to C:\WebSites\nuget-gallery\Themes. Names of theme folders are also significant.

Now you can go back to the Dashboard, this time picking Features, and enable Orchard.Gallery. This will also enable all dependencies.

Step 5: Configure Orchard and Orchard.Gallery

The next step is to go to Taxonomies and decide if you want to host NuGet packages only or also support Orchard modules and themes. We build Orchard applications so I just added a Packages entry to have all three.

It's almost time to set up the backend now, so have a look at Settings in the Dashboard.

First of all you might want to enable user registration or perhaps even require e-mail verification. If you do enable the latter, be sure to configure SMTP settings that are just below where I clipped the screenshot.

Next, in Gallery Settings you need to configure the location of the backend GalleryServer application. I decided to host it on the same server under /nuget-server.

Note that you won't be able to save settings unless you fill out the User To Report Abuse To field. Additionally, this needs to be a different user than admin - you will need to create one yourself.

Step 6: Configure GalleryServer

GalleryServer also uses SQL Server Compact Edition and creates a database on-the-fly like Orchard, but since it uses Entity Framework (whereas Orchard relies on NHibernate) and a crucial assembly - System.Data.SqlServerCe.Entity.dll - is not present anywhere in the source tree, you will need to either install SQL Server Compact 4 on the server or get the assembly elsewhere and copy it to bin.

Next configure the site in IIS. In my case this is /nuget-server pointing to C:\WebSite\nuget-server, which is a copy of the entire GalleryServer repository.

Because GalleryServer relies on the Orchard.Gallery module for authentication and authorization, you also need to modify ApplicationSettings.config. In my setup the relevant settings are as follows, the rest is left an modified:

Unfortunately, FrontEndWebSiteRoot can only contain the hostname, so you need to repeat the entire path in each setting.

Step 7: Test the setup with nuget.exe and the frontend website

Now you can finally see if things are really working. As a smoke test, first try getting the list of packages (which will obviously be empty, but shouldn't return any errors):

nuget.exe list -source http://polaris/nuget-server/FeedService.svc

Then log into the site as a non-admin user (you can can use the one created for the Settings page). In the usual place - MyAccount - you'll find your local API key. Now try uploading a package:

nuget.exe push elmah.1.1.nupkg 8cd3ad95-19a3-47d3-81af-090280077f24 -source http://polaris/nuget-server

Next check if it's really there:

nuget.exe list -source http://polaris/nuget-server/FeedService.svc

Now go back to http://polaris/nuget-gallery and check the My Contributions page and the global Packages page. Note that the latter sometimes needs a few minutes to refresh.

If all tests succeeded - congratulations! You are now a proud owner of your own private NuGet gallery. At this point you can use both nuget.exe and the website for all package operations, including upload and removal.

Step 8: SymbolSource integration

This is all great, but I hope you are now asking a very important question: how do I make use of the SymbolSource integration features introduced recently into NuGet?

SymbolSource has been built from the ground up with scalability and multi-tenancy in mind. Although we are not yet ready to release a standalone product that you could install on your own server, we can provide you with an entirely separate repository of symbols and sources.

You might have noticed that many of our URLs containt a Public prefix or suffix. This is a so-called company name and it identifies a separate namespace for users and packages. You can actually have a look at our NuGet symbol and source repository here (access to demo projects is unrestricted):

http://www.symbolsource.org/Caliper/Metadata/NuGet/Projects

The functionality of a private instance of SymbolSource is the same as the public one, and you can use it in the same way. For example, to upload a package, you can use this command:

nuget.exe push SecretLibrary.0.1.symbols.nupkg 8cd3ad95-19a3-47d3-81af-090280077f24 -source http://nuget.gw.symbolsource.org/Caliper/NuGet

And that's it. Absolutely no pain of the original Microsoft source indexing scripts, no need to take care of file system performance, and out-of-the box support in NuGet and Visual Studio. During upload, the correct NuGet gallery will of course be consulted to verify that you are a contributor for the particular project. To debug a package, all you need to do is add a familiar looking URL to Visual Studio:

http://srv.symbolsource.org/pdb/Caliper/TripleEmcoder/aR5bN6qkO4dT23g7WtfM3_0fBlP=

This is a private URL, which means that it contains a username and an authentication hash. No symbols or sources will be served out publicly.

What I've described so far in this blog post is a setup that we use in our everyday development. If you are interested in an environment like this, contacts us on Google Groups, Twitter or using the comment form below.

The next post will describe how SymbolSource handles permissions and how symbol and source access to repositories and projects can be restricted per user.

The new integrated NuGet workflow

Thu, 14 Apr 2011 17:26:47 +0200

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. What best speaks to us developers are examples, so please consider the following commands:

Create a regular and a symbol/source package in one go:

nuget.exe pack MyLibrary.csproj -Symbols

This will use the *.nuspec file included in the project file and generate MyLibrary.1.0.0.0.nupkg for nuget.org and MyLibrary.1.0.0.0.symbols.nupkg for symbolsource.org.
Save your API key for easier use of nuget.exe:

nuget.exe SetApiKey 78a53314-c2c0-45c6-9d92-795b2096ae6c
Push both packages to appropriate sites in one go:

nuget.exe push MyLibrary.1.0.0.0.nupkg

And that's it! After a short moment your package will be available not only for download through the NuGet package manager, but also for full on-demand debugging in Visual Studio with SymbolSource.

No registration on SymbolSource is required for this to work, but you can create an account later and associate your NuGet API key to manage past and future submissions.

Please remember to update your nuget.exe before trying this yourself.

Illustrated guide to symbol and source servers

Tue, 12 Apr 2011 11:23:10 +0200

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:

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

SymbolSource and NuGet after 1.2

Fri, 01 Apr 2011 23:41:44 +0200

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.

NuGet 1.1 is great, but 1.2 will be even better

Mon, 14 Feb 2011 10:42:32 +0200

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.

NuGet and OpenWrap demo packages

Mon, 07 Feb 2011 14:47:03 +0200

To work around our dependency on package maintainers publishing sources we prepared a small demo package (available from both NuGet and OpenWrap repositories) to show you how SymbolSource provides symbols and sources for libraries downloaded with your favourite package manager.

Follow these simple steps to test SymbolSource:

Configure Visual Studio.
Create a new Console Application.
Reference SymbolSource.DemoLibrary with NuGet or symbolsource-demolibrary with OpenWrap.

Use something from the library:

using System;
using SymbolSource.DemoLibrary.Calculator;


namespace ConsoleApplication
{
    class Program
    {
        static void Main(string[] args)
        {
            var c = new SimpleCalculator();
            Console.WriteLine(c.Add(1, 2));
        }
    }
}

Set a breakpoint and step into c.Add().

Now wouldn't it be so cool if everyone published sources to SymbolSource?