Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pack symbols in snupkg #1763

Merged
merged 1 commit into from Feb 2, 2020
Merged

Pack symbols in snupkg #1763

merged 1 commit into from Feb 2, 2020

Conversation

@AArnott
Copy link
Contributor

AArnott commented Jan 31, 2020

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

This comment has been minimized.

Copy link
Contributor Author

AArnott commented Jan 31, 2020

The Windows agent failure is another occurrence of #1764

@bording

This comment has been minimized.

Copy link
Member

bording commented Feb 1, 2020

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

This comment has been minimized.

Copy link
Contributor Author

AArnott commented Feb 1, 2020

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

This comment has been minimized.

Copy link
Contributor Author

AArnott commented Feb 2, 2020

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.

@AArnott AArnott force-pushed the AArnott:snupkg branch from 3902424 to 9b91bd8 Feb 2, 2020
@bording

This comment has been minimized.

Copy link
Member

bording commented Feb 2, 2020

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.

👍

@bording
bording approved these changes Feb 2, 2020
@bording bording merged commit 95009f0 into libgit2:master Feb 2, 2020
6 checks passed
6 checks passed
continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
libgit2sharp Build #0.27.0-preview.44+c811aa7b78.libgit2-6777db8 succeeded
Details
libgit2sharp (Linux) Linux succeeded
Details
libgit2sharp (Windows) Windows succeeded
Details
libgit2sharp (macOS) macOS succeeded
Details
@AArnott AArnott deleted the AArnott:snupkg branch Feb 2, 2020
@AArnott

This comment has been minimized.

Copy link
Contributor Author

AArnott commented Feb 2, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

2 participants
You can’t perform that action at this time.