Skip to content

guidance for embedding pdb in nupkg vs snupkg #255

@ctaggart

Description

@ctaggart

I'd like to revisit the change in guidance from f92b277 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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    externalquestionFurther information is requested

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions