ETA for NuGet/"public" release

[clairernovotny]

Hi,

Just was wondering what the thinking was for getting these bits published on to NuGet.org to increase discoverability?

[tmat]

We can definitely publish them to NuGet.

[clairernovotny]

That'd be great, thanks!

If you're curious, I'm using this in NuGet Package Explorer to convert PDB's to ppdb's so I can use a single API (S.R.M.) in getting the debug data (sourcelink) out of it:
https://github.com/NuGetPackageExplorer/NuGetPackageExplorer/tree/master/Core/AssemblyMetadata

You can see it in action by opening a nuget package that has a dll with embedded symbols or symbols alongside (and double-click that).

[tmat]

Hmm, converting the entire PDB is quite a hammer. I'm curious, how does NuGet Package Explorer use SourceLink?

[clairernovotny]

It extracts the source files location so they can be displayed and navigated to. Also serves as a sanity check that the sourcelink step worked correctly.

[tmat]

Cool! I assume it only works when the PDB is in the package? Or do you also support fetching the PDB from a symbol server?

[clairernovotny]

Right now it only works for files in the package (as legacy pdb needs the source binary for the conversion), or embedded ppdb's. Symbol server's aren't yet supported, but that'd be a cool additional check. If there's an easier way to get the data, I'm certainly game :)

[tmat]

Yeah, handling all scenarios gets a bit complicated.

In most of our tools (e.g. Roslyn) we use the API that matches the PDB format. For Windows PDBs, we use managed library (Microsoft.DiaSymReader package) that wraps native APIs (Microsoft.DiaSymReader.Native package). For Portable we use SRM. We encapsulate the format specific code behind an abstraction tailored to our usage, so that the rest of the code doesn't need to deal with differences between Windows and Portable PDBs.

The VS debugger uses similar approach but for historical reasons chose to use ISymUnmanagedReader APIs as the abstraction layer (because they already had a lot of code using it). That's where Microsoft.DiaSymReader.PortablePdb package comes in - it implements ISymUnmanagedReader on top of SRM. But I wouldn't recommend that for your app since you don't have backward compat requirements.

For reading file information and SourceLink I think the former approach would work well. It is pretty straightforward to use Microsoft.DiaSymReader APIs for reading Windows PDBs.

[tmat]

Re symbol server: we now do recommend customers using snupkg for publishing Portable PDBs, rather than embedding them into their main packages. Fetching PDBs from symbol server would be a bit more work for you. https://github.com/dotnet/symstore should provide the necessary tools for that.

[clairernovotny]

Thanks -- will see. As you recall, I'm not the biggest fan of the snupkg recommendations. I much prefer the pdb's in the nupkg where they're always available.

[tmat]

I hear you, unfortunately not everyone has fast internet connection and we need to be considerate of customers who experience slow restore times and not make their situation worse.

[clairernovotny]

Not related to this thread, but one thing that'll help is if the VS debugger symbol loader could parallelize and load symbols in the background. Combined with if it could be eagerly done while the code editor was open before debug even began. This becomes important for Ctrl+F5 scenarios where I want to step-in to arbitrary code on a navigate. The symbols should be eagerly available so sourcelink info can be there to retrieve the source file.

[tmat]

We can certainly look for some improvements in the symbol loader.
/cc @chuckries

[OmerRaviv]

Just wanted to +1 this request - we have been using pdb2pdb for years and it's a great tool and very handy. Would definitely make things more convinieint if we could consume it via nuget.org directly.

[peterhirn]

Please push this package to nuget.org. Prerelease version is fine. It is very annoying to put this in all my projects:

    // Not available on nuget.org, see https://github.com/dotnet/symreader-converter/issues/154
    source https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet-tools/nuget/v3/index.json
    nuget Microsoft.DiaSymReader.Pdb2Pdb prerelease

Release as dotnet-tool (as suggested here #208) would be even better.