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:

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

4. 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));
           }
       }
   }
   

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

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

It's been a while since we posted here, but now we're ready to share what we've been preparing in the mean time. We hope that you're using SymbolSource in your daily work and haven't noticed the inherent delays in symbol/source publishing that happen after project releases. We are doing our best to keep up, but this is a game that simply cannot be won.

However, with the new features that we are announcing today there will be no need for such a chase anymore.

From now on anyone will be able to upload symbols and sources, and it applies especially to NuGet and OpenWrap package maintainers. If you are one, we invite you to join the beta program and let us know you'll be publishing on behalf of a particular project.

We have added two interesting projects to SymbolSource that make path manipulation much easier than when using System.IO.Path and allow some additional scenarios. This is how they are described by their authors:

FileDirectoryPath

NDepend.Helpers.FilePathDirectory is the library used by the tool NDepend to handle common path operations. Benefits of the NDepend.Helpers.FilePathDirectory over the .NET Framework class System.IO.Path include:

• Strongly typed File/Directory path.
• Relative / absolute path conversion.
• Path normalization API
• Path validity check API
• Path comparison API
• Path browsing API.
• Path rebasing API

Read more at http://filedirectorypath.codeplex.com.

FluentPath

Since .NET v1, lots of good things happened to C#: lambda expressions, extension methods, optional parameters to name just a few. Outside of .NET, other interesting things happened as well. For example, you might have heard about this JavaScript library that had some success introducing a fluent API to handle the hierarchical structure of the HTML DOM. You know? jQuery.

Knowing all that, every time I need to use the stuff in System.IO, I cringe. So I thought I’d just build a more modern wrapper around it. I used a fluent API based on an essentially immutable Path type and an enumeration of such path objects. To achieve the fluent style, a healthy dose of lambda expressions is being used to act on the objects.

Read more at http://fluentpath.codeplex.com.

With a slight, unplanned delay we can now announce support for the latest releases of Castle projects:

• Castle ActiveRecord Integration 1.1.0
• Castle Automatic Transaction Management 2.0.0
• Castle Scheduler 1.0
• Castle Synchronize Facility 1.1
• Castle Transaction Services 2.0.0

We updated the look and feel of pages displaying projects and their versions that we support and their contents. With this change we hope to soon make them more even informative.

We also noticed that a lot of our visitors are coming from search engines while looking for code fragments. Because of this, one of our focuses in the nearest future will be to provide more information about the binaries, symbols and sources that we host and to implement code navigation functionality directly on the website.

Due to a bug found recently, you might be unable to download source files when debugging some of the projects for which we provide symbols.

The problem has been resolved and appropriate PDB files have been corrected. However, because Visual Studio caches those files locally, you will need to delete them on your machine manually (or just clear the entire cache folder). Be aware that these files can also be stored in the current user's temp folder.

Affected symbol files exist under the following projects and versions:

• AutoMapper 1.1
• Castle Project Core 1.2.0
• Json.NET 3.5 Release 6
• Microsoft Enterprise Library 4.1 – October 2008
• Microsoft Enterprise Library 5.0 - April 2010
• Microsoft Enterprise Library 5.0 - Beta2
• MVC Contrib 1.0.0.987
• MVC Contrib 1.5.996.0 RC
• MVC Contrib 2.0.34.0
• MVC Contrib 2.0.36.0 for MVC2 (RTW)
• Unity 1.2

If you are using any of these releases with SymbolSource, please make sure you delete their PDB files from your local environment. We apologize for the inconvenience.

We have created a Google Group at http://groups.google.com/group/symbolsource for posting library suggestions or any other feedback on the SymbolSource project.

We hope that it will become the home for discussions on the project's current and future shape. We invite you all to join and take part.

As you might have noticed, we are constantly working on expanding our base of supported projects. We are happy to inform that recently these project realeases where added to our symbol and source repository:

• Autofac 2.1.13.813
• AutoMapper 1.0 RTW
• Unity 1.2
• Unity 2.0 Beta2
• WPF Extensions 1.0
• WPF Toolkit June 2009
• WPF Toolkit February 2010

We are also working on making our project and version listings more informative and user friendly.

There was a problem with the user registration process which caused errors when accessing the Visual Studio tab and the personalized symbol server link. This is now resolved and there is no need to register again. Everything should work fine with your existing accounts and any new accounts that will be created.

We kindly ask all people that registered with us to try again and apologize for the inconvenience.

While adding projects to our repository we have come across two main issues that prevent us form adding a particular project:

1. Official binaries are compiled with symbol generation disabled.
2. Releases are made rarely, instead encouraging users to use nightly builds.
3. Binary releases are published without corresponding source distributions and source repositories are not tagged with the release.

These could all be considered bad practises on their own, but in case of SymbolSource these are often dealbreakers preventing us from supporting symbols and sources for a particular release.

Let's take a look at each of these issues.