Setting up your own SymbolSource Server: step-by-step
Edit: This post is rather out-dated, and I would now recommend you get yourself out of the symbols server hosting business, and instead, use MyGet's Symbol Server capabilities.
More info: http://docs.myget.org/docs/reference/symbols.
I've already explained why everyone should be using a symbols server. In that post, I explained that TFS comes with its own integrated symbols server, but at the moment it doesn't play very nice with NuGet packages. Or maybe you are not using TFS at all.
That's where SymbolSource comes in. NuGet has the ability to create symbols packages, so you can easily push them to a symbols package repository. This is exactly what SymbolSource offers, either as a public or private repository on SymbolSource.org, or as a separate cloud-based instance of SymbolSource where you also can manage users and repositories. Both plans are still in an unlimited free beta mode, so give it a try.
As much as I am a huge fan of the hosted SymbolSource offering, some people prefer to host code, symbols and packages on their own infrastructure, if only to troll some sys-admins or slow down development (if you're a manager, I'm talking about security).
With the release of the SymbolSource community edition, I figured it was about time to try it out for myself.
Prerequisites
Before you open Visual Studio and search NuGet for the 'symbolsource' keyword, you'll have to install the Debugging Tools for Windows. As I'm going to try it out on a Windows Azure Virtual Machine running Windows Server 2012 RC (living on the edge aren't we), I'll simply install the Windows SDK for Windows 8 Release Preview which contains the Debugging Tools for Windows as a standalone component.
Keep track of the installation path as you will need it later on.
Setting up your basic SymbolSource server
If you are familiar with setting up your own NuGet server (if not, check out this book), you'll notice that setting up your own SymbolSource server is peanuts. Very similar to the NuGet.Server package, SymbolSource provides you with a SymbolSource.Server.Basic package on NuGet (they just released v1.1.0 so go get it while it's hot!). Let's get this thing rolling...
Creating the Web application
I started off an empty ASP.NET MVC4 application.
Next I ran the following script in the NuGet Package Manager Console:
Install-Package SymbolSource.Server.Basic
For those who prefer clicking there way through the UI, you can achieve the same by right clicking your Web project's references, select Manage NuGet Packages, and query the NuGet official feed for the term "SymbolSource.Server".
Installing this package injects a ton of dependencies into your consuming Web application project. This isn't a bad thing, really, because you get a whole lot of functionality by simply installing this single NuGet package. It even comes with ELMAH logging preconfigured, so you get logging out of the box.
Note: Don't forget about security! See http://code.google.com/p/elmah/wiki/SecuringErrorLogPages for more information on remote access and securing ELMAH.
Now's the time you need to configure the installation path of Debugging Tools for Windows. To do so, open the Web.config file and adjust the
Windows Server 2012 / Windows 8:
<add key="SrcSrvPath" value="C:\Program Files (x86)\Windows Kits\8.0\Debuggers\x64\srcsrv" />
Earlier versions of Windows:
<add key="SrcSrvPath" value="C:\Program Files\Debugging Tools for Windows (x86)\srcsrv" />
You can now start the application and browse the home page shown below.
All the information you need, including all required URLs, is listed on the application's start page.
- Visual Studio Debugging URL - You need to configure this URL in the Debug settings of your Visual Studio development environment. More info and a recommended setup are documented on the SymbolSource Web site.
- NuGet Symbols Packages Repository URL - This is the NuGet package repository where you should push your symbols packages to.
- OpenWrap Repository URL - Yep, SymbolSource supports both NuGet and OpenWrap!
- Self-diagnostics - Very useful and very nice from the SymbolSource guys to provide this. This will help you verify whether the prerequisite is installed and your Web site is configured correctly to provide a fully functioning SymbolSource basic server. Shield this info from the public! No one needs to know...
If you look at the previous image, you'll notice that the NuGet push test failed with an InternalServerError. Checking this on the server itself reveals that the application has no access to the App_Data folder. To fix this, simply add write permissions for the IUSR on the App_Data folder through IIS Management Console. Make sure you do the same for the Data and the Index folder.
There's one last thing you need to do: modify your web.config and add the following elements:
<system.webServer>
<modules runAllManagedModulesForAllRequests="true" />
</system.webServer>
If all went well, your home page should indicate that your server has been configured correctly.
Creating and pushing symbols packages
A symbols package has the *.symbols.nupkg extension and contains only DLL, PDB, XMLDOC and source files. To create them, add the -Symbols option to the NuGet pack command. You should see two packages being created instead of one. A detailed description on the symbols package contents and structure can be found on the online NuGet Documentation.
Quoting from the SymbolSource documentation:
"At this moment, the server accepts any NuGet API key, but you are free to secure it using any of the IIS authentication capabilities."
This means you can easily push the symbols package using the following command:
nuget push {packageID}.symbols.nupkg {API key} -source {url}
The server will ignore your API key (as it accepts anything at the moment). Replace the {url} placeholder with the NuGet symbols packages repository URL you found on your server's home page.
That's it! Happy packaging!
Leave a Comment