guidance for embedding pdb in nupkg vs snupkg

I’d like to revisit the change in guidance from https://github.com/dotnet/sourcelink/commit/f92b277cf08caf4b86425aad1fc4cdebd63c6650 as a fix to #229.

Including PDBs in the .nupkg is generally no longer recommended as it increases the size of the package and thus restore time for projects that consume your package, regardless of whether the user needs to debug through the source code of your library or not

This is only when publishing to NuGet.org. The only time a snupkg would be useful is when publishing to NuGet.org. If you are using any other NuGet feed such as:

• Azure Artifacts NuGet feed
• Artifactory NuGet feed
• MyGet.org feed
• AppVeyor feed
• many more…

Including PDBs in the .nupkg works all of those places and NuGet.org as well. It works at every step of development. It decreases the size of the nupkg download only slightly. The same can be said for embedded XML documentation.

Symbol Servers need to retire

One of the most time frustrations for me is when Visual Studio debugger HTTP queries symbol servers for symbols when I want to debug something. I should be able to lock dependencies and have dotnet restore bring all of the available symbols asynchronously for all of the locked dependencies directly after a restore. It would be nice if all NuGet servers supported snupkg too and dotnet restore of symbols would look for snupkg first before querying Symbol Servers.

[gilescope]

The NuGet team collected numbers on this and the results show that this “slight” increase significantly affects download times in some regions.

I expect that this too would be fixed in future. Meanwhile I would gladly trade slower download times for a simpler debugging experience.

[TFTomSun]

@ctaggart I have exactly the case that I want to use local feeds and Artifactory instead of Nuget.org. Can you please point me to the current best approach to embed PDBs and source files? I want to use it for debugging as well as for code coverage analysis.