1

While debugging I can step into external dependencies and our own nuget packages, if they were compiled to symbol packages (MyProject.snupkg) and uploaded to the nuget server. This is how we do it for our own nuget packages on our private nuget server.

I discovered the Source Link tool, whose readme states

Source Link enables a great source debugging experience for your users, by adding source control metadata to your built assets

What is the difference between that and the setup I've described above? And is there a benefit to using both at the same time?

(I've found existing SO questions for configuring Source Link, but none about the difference to symbol packages.)

lonix
  • 14,255
  • 23
  • 85
  • 176

1 Answers1

3

I consider Source Link as some kind of evolution from symbol packages.

With the symbol packages, you always had two files:

  • MyPackage.nupkg (contains the assembly itself)
  • MyPackage.snupkg (contains the debug symbols)

So basically the debug symbols are shipped as a separate NuGet package (the snupkg file) and the relationship to the underlying source code is broken. Microsoft lists some more constraints (see here).

Now since a lot of source code is open anyway (e. g. on GitHub), why not link the NuGet package directly to the sources? That's what Source Link does: it bridges the gap between the referenced assembly and its source code, without relying on an intermediate file (like snupkg).
This enables true deterministic builds, i. e. one can verify which Git commit was used for an assembly of a NuGet package.

mu88
  • 4,156
  • 1
  • 23
  • 47
  • 1
    Thanks. So if I understand correctly, both approaches do the same thing - but Source Link is newer. The old way I must pack and push a symbol package to a nuget server, whereas the new way I just point at the remote source repo (and the SL library will download and do the rest during debugging). So it's easier to use Source Link, but only if the source code is hosted publically. – lonix Sep 15 '22 at 10:29