Pack symbols in snupkg

[AArnott]

pdb's tucked inside a .nupkg don't get indexed by nuget.org, and as a result, customers who are debugging an application that includes this library won't be able to find symbols automagically.

I was a late holdout myself. But when I discovered that publishing snupkg allowed VS to automatically find PDBs for dll's (even without the nuget package itself present) I was sold.

Now, technically we could put symbols both in the nupkg and also upload an snupkg. I'm curious though whether there really is a use case for symbols remaining in the nupkg at this point.

[AArnott]

The Windows agent failure is another occurrence of #1764

[bording]

pdb's tucked inside a .nupkg don't get indexed by nuget.org, and as a result, customers who are debugging an application that includes this library won't be able to find symbols automagically.

Except that if they are already right there on the disk next to the assembly, there's no need for magic. 😄

Overall, I don't really find the arguments for why we need separate symbol packages convincing, especially when you look at how much smaller portable PDB files are. Maybe it makes sense for the actual framework symbols, but not for a single package's symbols.

I was a late holdout myself. But when I discovered that publishing snupkg allowed VS to automatically find PDBs for dll's (even without the nuget package itself present) I was sold.

However, does that work for any other tool? Sure, VS now has the ability to find those symbol packages, but what about all the other tools people use?

It's often a desirable thing to include PDBs in your production output to ensure that exception stack traces have line numbers, and separate symbol packages make that much more complicated to do.

Now, technically we could put symbols both in the nupkg and also upload an snupkg. I'm curious though whether there really is a use case for symbols remaining in the nupkg at this point.

Overall I still think including the PDB directly in the main package is better, but there is still one open bug that will prevent Source Link from working, so that is one scenario where having the separate symbol packages would be helpful.

At this point, I don't mind adding the symbol packages, but I'd like to keep the PDB in the main package also.

[AArnott]

However, does that work for any other tool?

Sure. It's just standard symbol server protocol. But you have to put the NuGet.org symbol server URL into it.

[AArnott]

It's often a desirable thing to include PDBs in your production output to ensure that exception stack traces have line numbers, and separate symbol packages make that much more complicated to do.

I think you win some and lose some. Yes, I want PDBs for my entire application, and when running unit tests. But when I'm debugging something for which I don't have source code, having the PDB indexed in a symbol server means my debugger Just Works and can download source code for stepping as well.

I'll modify this to leave symbols in the nupkg but also produce an snupkg so we can get the best of both worlds.

[bording]

But when I'm debugging something for which I don't have source code, having the PDB indexed in a symbol server means my debugger Just Works and can download source code for stepping as well.

But with a Source Linked PDB included in the package, that also works, so I'm not sure what symbol packages are enabling here.

I'll modify this to leave symbols in the nupkg but also produce an snupkg so we can get the best of both worlds.

👍

[AArnott]

But with a Source Linked PDB included in the package, that also works, so I'm not sure what symbol packages are enabling here.

It enables my debugger to automatically get the PDB when I didn't use nuget to get the dll in the first place. For example, if I'm stepping through an application that shipped libgit2sharp.dll, and of course didn't ship the pdb, a pdb in a nupkg would not help me at all. But a pdb in an snupkg got indexed and my debugger can find and download it.