Repository navigation
SourceLink is a joke #1403
Description
The goal of the project is to enable anyone building NuGet libraries to provide source for their users with almost no effort.
Never, ever, despite numerous hours lost, I was able to make this thing work on any of my projects. Easy you say? Ton of strange, undocumented switches and options to configure. Anyone? Well it fails on basic scenarios like one solution having multiple NuGets in subprojects.
Debuging of external libraries was always hell in .NET, since day one. I always had wonder how come that Java and IDEs like IntelliJ could make decompilation and debugging of the external code just work out of the box, and Microsoft after almost 25 years is still struggling? To the point that some horrendous technologies, that requires constant access to source code repository hosted online, emerges?
Guys, this is NOT the way. Again.
Activity
tmat commentedon Apr 8, 2025
Which source control server (GitHub, GitLab, etc.) is your repo on?
EvilVir commentedon Apr 8, 2025
Depends, I had various projects on Azure DevOps' Git, on BitBucket where I tried to enable SourceLink for past few years. Now I'm fighting with local Gitea installation.
I have a solution with ~12 projects in subfolders (not sub-modules, just plain folders) from which 12 NuGets are built. All I get, after hours of fighting is this for every project, during build:
And here's my latest config (but tried almost all combinations of these options):
And here's the build command on Gitea's build pipeline:
I want it to be standard NuGet nupkg + snupkg with symbols and everything else. No go :( Any ideas?
zivkan commentedon Jun 25, 2025
I just saw this issue. TL;DR is that you need to publish your pdbs to a symbol server, and configure your debugger to use that symbol server.
Sourcelink embeds source control URL + commit hash + source file name into the pdb, so once the debugger has the pdb, it knows where to find the original source code. But the debugger has to get the pdb from somewhere. To the best of my knowledge, debuggers don't know anything about nuget, but there's a protocol called Symbol Server that has existed long before NuGet ever did. Even if a debugger did know about nuget, the nuget protocol doesn't support symbols in any way.
Azure Pipelines has a task PublishSymbols@2 which can push your pdbs directly to its own symbol server. Their docs also explain how to configure Visual Studio to use its symbol server
snupkg was created so that packages that are uploaded to nuget.org can also have their symbols uploaded in a separate file. I'm not aware of any other Nuget server that supports snupkgs (maybe BaGet does). Azure Artifacts for example only supports direct pdb publishing, it never supported either snupkg or symbols.nupkg.
All of this can be avoided if you put the pdb in the "normal" nupkg, along with your dlls. If you do this, then restoring the package will have both the pdb and the dll, and if you make sure your build copies the pdb into the bin directory, then the debugger can load the symbols without querying a symbol server. But it has other implications, like the package bloating in size and package consumers might accidentally start deploying those pdbs to their production servers, which could be unwanted (or forbidden by security policy). So, it's a tradeoff.
If you're using some NuGet feed that doesn't have a built-in symbol server, then you either need to bloat your nupkgs, or you need to migrate to a different nuget server. If you're using a nuget server with symbol server support, then you need to check its docs on how to actually publish the symbols, as there is no standard way to publish the symbols.