Including PDBs in package

Sep 12, 2011 at 5:54 PM

My company typically deploys PDBs for all of our internal line of business applications to aid in debugging production issues. I want to include PDBs in all of the Nuget packages that I have written for the company's internal use and that I am hosting on an internal Nuget feed. That way any appliation that uses these packages will automatically include the PDBs in its build output. However, it appears that the only symbol support that is currently included in Nuget is for creating a separate symbol package for Visual Studio debugging. I can create a a <files> section in my nuspec file that includes the PDBs, but then I lose the advantage of the the Nuget conventions.

1) Can functionality be added to the Pack command to support including the PDBs directly in the package?

2) In the meantime, can someone suggest what elements to include in my <files> section in order to mimic as closely as possible the default convention-based behavior of Pack?

Sep 22, 2011 at 1:45 AM

Yes, we need this too.  I want to be able to debug into a package that I built locally and cannot figure out how to do that.  If the .pdb's were included in the package, then everything would work great.

Sep 22, 2011 at 11:07 PM

Can someone on the NuGet team respond to this?  Is there a work around for this?  I thought I could work around this problem by manually adding the .pdb to the .nuspec, but it turns out that even if I do that, it still is not included in my .nupkg file.  This is a major issue for cross-package development as I really need to be able to debug into a package I just built on my local machine.

Sep 22, 2011 at 11:16 PM

I assume you're building a package from a profile file right?

Sep 22, 2011 at 11:21 PM

Where are you hosting your packages? In a network share? In a custom gallery using the NuGet.Server package?

Do you absolutely need the PDBs in the same package? What if we did something where as long as the symbols package is next to the regular package, we made debugging work? This might mean making the NuGet.Server act as both a regular feed and a symbols feed somehow.

Currently, we have no feature requests for this yet.

Sep 22, 2011 at 11:44 PM

Thanks for the response.  The use case is this:

We build several packages across multiple source repositories at our company.  I'm working on on a package in our "shared code" repository, and I am consuming some of the changes in my web app repository.  Up until now, we have not used NuGet to package our shared libraries, and have just pushed .dll's around.  We setup a "local import" process so that instead of pulling the latest assemblies in from our CI build server (or NuGet feed), I can instead pull them from my shared source repository.  That way I can debug into my local code in the shared library from my web application.

I would like to start packaging our shared libraries as NuGet packages.  The idea is that we would continue to support two separate import would be to pull in the package from the company feed (via nuget.exe install), and the other would be the "local import" mode where we essentially use the export directory of our shared source repository as our NuGet feed, and run nuget.exe install against it.  That way I have a choice over whether to import the official bits, or local bits that are easy to debug into.  However, if I cannot package the .pdb's with my local packages, then there is no easy way for me to debug into the code. I have looked at generating the symbols packages, but I cannot figure out how those help me out for my use case.  Making debugging work with a symbols package that sits right next to the regular package would be fine.  But that doesn't appear to work at the moment. Any advice on how I could make that happen would be helpful.

@dfowler: I'm not sure I know what you mean about building from a "profile"?  Could you clarify?  I have tried building from the .csproj as well as a manually created .nuspec, it seems even when I include a manual reference to the .pdb in the .nuspec, it excludes the .pdb from the "lib" folder.

Sep 23, 2011 at 12:46 AM

It sounds like I am in a situation very similar to Andy. We will likely be hosting our packages on a network share, but we could setup a local web server also/instead.

In my case the pdbs aren't just for debugging, we want to deploy them (internally) with our applications. So a solution based on Visual Studio's symbol support doesn't really fit the bill.

It sounds like this is another one of those things that comes up more in a corporate environment, and isn't really an "itch in need of a scratch" for most of the Nuget team. I keep hoping that I will get time to actually dig into the Nuget source and maybe even make some modifications so that it would better fit in our environment, but that hasn't happened yet.

Sep 23, 2011 at 12:58 AM

So I figured out a work around for now.  It turns out that nuget.exe was excluding my .pdb file (even though I was explicitly including it in the nuspec) because I was passing the -Symbols switch.  When I stopped passing that switch, it no longer removed the .pdb.  So for now, my workaround is to explicitly include the .pdb in the .nuspec.  If debugging could work automatically if you include a .symbols.nupkg file alongside your regular .nupkg as Phil suggested, that would be awesome.  I've looked into setting up a symbol server and it looks not-trivial.

Sep 23, 2011 at 1:40 AM

Please create an issue with what behavior you’d like to see. I can’t promise we’ll get to it soon, because as commongenius stated, it’s not an itch we have because the integration is working great for us already.

We do accept code contributions! J Maybe it’s a small tweak to make this work for all we know.

Sep 23, 2011 at 5:32 AM

Thanks Phil.  I have created the issue here:  I think it would probably be a pretty easy thing to add.  I'll look into getting a pull request together for it. is awesome for published packages, but doesn't really help with packages in development, or internal company packages (yes, I'm aware that symbolsource recently added support for private feeds, but that doesn't quite fly at my company).  It would really be great to have a good debugging story for symbol packages without as well.  Until then, simply including the .pdb's in Debug builds packaged from the .csproj should resolve my issue.

Oct 3, 2011 at 12:22 PM

Would you be willing to share some of your company's insight on SymbolSource? Why doesn't it "quite fly"? Is it because of the external storage, or a lack of a formal agreement at the moment? What could we do to better accommodate to your needs?

In general, including PDBs in packages will get you an enhanced debugging display, but not source stepping. That's what we'd like to help everyone solve with SymbolSource.

Oct 7, 2011 at 11:08 PM


I'm not sure what benefit SymbolSource would provide us. We already index our symbols with the location of our source code in source control, so when a developer needs to debug into source, Visual Studio automatically gets the source. This is currently very effective in our environment; all we need to get it working with Nuget is the ability to easily include PDBs in packages. This would also allow us to easily deploy the PDBs with our client applications, which gives us better information when we get stack traces and dumps from production errors; that is not something SymbolSource could provide.

Oct 8, 2011 at 7:55 PM

@TripleEmcoder The primary showstopper would be the uploading of our source code to a third party.  Legal/Security departments just won't go for it.  If we could somehow self-host a SymbolSource instance, then it would be workable.

@commongenius: What source code repo do you guys use?  Indexing used to work for us when we were on TFS, but we haven't figured out how to make it work since we switched to git.

Oct 10, 2011 at 5:57 PM

@andyalm, Our source code in Subversion is indexed. We also have some code in TFS that I never set up with indexing (good to know that it's possible). I have never tried with git.

Aug 29, 2012 at 11:55 AM

I have just found this thread and the associated issue (which is sitting, unloved and unwanted in the ProductBacklog) as I was having the same problem.

For those wondering why we want to include PDBs, look at my options:

Option 1: Use SymbolSource

For security/confidentiality reasons we cannot host on SymbolSource (private or otherwise) so that's not an option.

Option 2: Host your own SymbolSource server

Okay, so we could host our own SymbolSource server: here are the steps:

  1. Download the source code
  2. Compile the code and ensure there are no errors
  3. Find a server to host it on, install and configure
  4. Test server, try loading packages 
  5. Amend every nuget package build to update the internal SymbolSource server
  6. Go round every VS instance in the company trying to ( I have three of my own - Desktop, laptop and home pc) reconfigure it to allow use of a symbol server, and configure it to use the internal symbol server

Option 3: Include PDB in Package

Wait for it....

  1. Include the PDB in the nuget nupkg file

Sadly the pack option does not have an option to do this automatically.

My workaround is to add  "<files>" section. The problem is that I have to specify "bin\Release\mypackage.pdb" - there does not seem to be a variable we can use to pick up the output directory. I tried "mypackage.pdb" but that did not work either.

Jan 16, 2014 at 7:32 PM
Edited Jan 16, 2014 at 7:37 PM
Hey quango, I feel your pain. A possible enhancement to your Option 3 work around is to use "bin\*\mypackage.pdb". This way it will pick the pdb file up from bin\Debug or bin\Release. You run into a problem though if the pdb file exists in both directories, as NuGet will throw a duplicate key error when trying to pack the package. So if each machine (developer or build server) only builds the project in one configuration (i.e. Debug or Release) this workaround will work for you.
Jan 18, 2014 at 11:44 PM
Ok, it turns out I was being silly. Looks like this functionality does exist already, as outlined in the NuSpec Reference Docs; not sure what version it was added in though.

Here's the example they give:
<file src="bin\$configuration$\$id$.pdb" target="lib\net40\" />