consuldotnet
consuldotnet copied to clipboard
G-Research
Add NuGet symbol package
See https://devblogs.microsoft.com/nuget/improved-package-debugging-experience-with-the-nuget-org-symbol-server/
Personally I'm more fan of shipping the pdb inside the nuget than using a symbol server. Less reliance on internet and nuget infra.
Just my 2 cents :-)
Its probably worth considering official guidance on when to include a pdb in a package:
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. That said, .snupkg symbol packages have some limitations:
- They do not currently support Windows PDBs (generated by VC++, or for managed projects that set build property DebugType to full)
- They require the library to be built by newer C#/VB compiler (Visual Studio 2017 Update 9).
- The consumer of the package also needs Visual Studio 2017 Update 9 debugger.
- Not supported by Azure DevOps Artifacts service. Consider including PDBs in the main package only if it is not possible to use .snupkg for the above reasons. For managed projects, consider switching to Portable PDBs by setting DebugType property to portable. This is the default for .NET SDK projects, but not classic .NET projects.
Link: Alternative PDB Distribution
That being said Sourcelink is a nice feature for package source debugging: https://github.com/dotnet/sourcelink
I would prefer shipping pdbs with the nuget package itself instead of using snupkg format as the latter is not yet supported in Rider (https://youtrack.jetbrains.com/issue/RIDER-21735) and in Artifactory (https://www.jfrog.com/jira/browse/RTFACT-5972).
