Including PDBs in package

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?

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.

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.

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.

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 modes...one 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.

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.

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.

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 symbolsource.org 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.

Thanks Phil. I have created the issue here: http://nuget.codeplex.com/workitem/1543. I think it would probably be a pretty easy thing to add. I'll look into getting a pull request
together for it.

symbolsource.org 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 symbolsource.org as well. Until then, simply including the .pdb's in Debug builds packaged from the .csproj should resolve my issue.

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.

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.

@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.

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....

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.

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.