API / endpoint for snupkg's

[clairernovotny]

We need an API / metadata on the package that points to a snupkg, if the package has one.

The scenario is that tooling may need to download all symbols for a NuGet package as part of validation steps, such as ensuring the Source Link information is properly embedded.

Currently the only option is to use the CDN endpoint, and check with a HEAD: https://globalcdn.nuget.org/symbol-packages/{lowercase ID}.{lowercase normalized version}.snupkg

There's no guarantees around this endpoint, however.

Downloading each PDB via the symbol server API is less efficient as each pdb needs to be calculated and downloaded, if published, individually. For validation scenarios, all pdb's would be required anyway.

--

There's another scenario where people find it generally useful to see what's in the snupkg package, downloading and opening with a tool like NuGet Package Explorer.

--

NuGet Package Explorer intends on helping people know if packages are properly Source Linked and thus needs to perform all these steps: NuGetPackageExplorer/NuGetPackageExplorer#904

[loic-sharma]

This is a great idea! I would love to have a similar "debuggable" indicator on nuget.org and Visual Studio. I think at the bare minimum we could add a documented service index entry for the .snupkg resource.

Downloading each PDB via the symbol server API is less efficient as each pdb needs to be calculated and downloaded, if published, individually.

Even with the .snupkg API, wouldn't you need to do this regardless? A package may have .DLLs whose symbols are on the Microsoft symbol server but not in its corresponding symbol package.

/cc @cristinamanum who worked on the symbols feature.

[clairernovotny]

I think it's important to define what dll's are relevant to be validated. For now, in NPE, I'm just checking ones in lib and runtimes. I'm not validating files in tools, etc. Therefore, I expect all the files to be present in the snupkg and not need to check any symbol servers.

I've just released 5.6.18 of NPE with support for Source Link validation. I only support snupkg checking if the package came from NuGet.org and I think that's a huge issue and limitation.

[loic-sharma]

I only support snupkg checking if the package came from NuGet.org and I think that's a huge issue and limitation.

Yup that's very fair.

I've just released 5.6.18 of NPE

I just played around with the latest version, it works like a charm! :)

I think it's important to define what dll's are relevant to be validated. For now, in NPE, I'm just checking ones in lib and runtimes. I'm not validating files in tools, etc. Therefore, I expect all the files to be present in the snupkg and not need to check any symbol servers.

Even with that lib and runtimes folder limitation, I think you would still need to fallback to symbol servers in certain scenarios. For example, Microsoft.Extensions.Logging.Abstractions has published its symbols on the Microsoft symbol server and does not have a corresponding .snupkg on nuget.org.

[clairernovotny]

Good catch re Microsoft.Extensions.Logging.Abstractions. I was really hoping to avoid poling symbol servers as that's a whole other game.

[loic-sharma]

I was really hoping to avoid poling symbol servers as that's a whole other game.

I've found this repository invaluable: https://github.com/dotnet/symstore

I took a crack at this problem a while back when I was trying to prototype a similar feature. Maybe it might help! https://github.com/loic-sharma/NuGet.Quality/blob/6fcb1d2e47568a721d1d6fdf62b161c22ab2ad8a/Program.cs#L162-L188

[clairernovotny]

@loic-sharma I just published 5.6.23, which checks the Microsoft symbol server for Microsoft files. It fixes this.

I saw your TODO about ensuring symbols match the PE file... any leads on that?

[loic-sharma]

I saw your TODO about ensuring symbols match the PE file... any leads on that?

Yes nuget.org does this validation at .snupkg ingestion. The steps are:

1. Get the checksum entries from the DLL (see this)
2. Find a PDB that corresponds to the DLL
3. Check that PDB's hash matches at least one checksum entry from the DLL (see this).
   1. For each checksum entry from DLL:
      1. Grab the algorithm name from the checksum entry
      2. Calculate the PDB's content hash using that hash algorithm name (see this)
      3. If that PDB content hash matches a checksum entry, pass! (see this) 😀
   2. If no PDB content hash matches the checksum entry, fail! 😠

Please let me know if you have any questions

EDIT: By the way, I believe this checksum entry stuff only works with portable PDBs. I believe DLLs don't have checksum entries for Windows PDBs.

[TheXenocide]

We're in the process of changing how we deal with NuGet packages and this could be helpful for us. Honestly it would be very convenient if NuGetGallery was also a symbol server in the same way NuGet.org is; simply publish a symbol package and the symbols are handy for debug! Combine with Source Link and we have minimal configuration universal debugging.

This is not on our short-term list though, just adding this to my wishlist and subscribing to updates :)

[loic-sharma]

@TheXenocide are you running your own private NuGet server? If so, some third-party NuGet servers also work as symbol servers like Sleet or BaGet. For a full list of third-party servers see this documentation: https://docs.microsoft.com/en-us/nuget/hosting-packages/overview

[TheXenocide]

@loic-sharma we currently use NuGet Gallery for our private nuget servers. We previously used the TeamCity integrated server but had significant performance issues with it which were causing other issues in our builds, so we separated from that and have just been using this project as our NuGet repository. We could consider an alternative, it just came to mind since NuGet.org has built-in symbol server support and I was thinking it would be nice to have it in our local version of the gallery as well. We're honestly a little ways out before we could consider employing any of this anyway (and would more particularly benefit from it once there's a TFVC implementation of Source Link), just thought I'd note that it would be nice in combination with this here.

[clairernovotny]

@TheXenocide you could also just include the PDB in your main nupkg and not worry about symbol servers at all. Add this to your props/csproj file:

https://github.com/clairernovotny/DeterministicBuilds/blob/master/Directory.Build.props#L10