Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ETA for NuGet/"public" release #154

Open
clairernovotny opened this issue Jun 10, 2019 · 14 comments
Open

ETA for NuGet/"public" release #154

clairernovotny opened this issue Jun 10, 2019 · 14 comments

Comments

@clairernovotny
Copy link
Member

Hi,

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

@tmat
Copy link
Member

tmat commented Jun 11, 2019

We can definitely publish them to NuGet.

@clairernovotny
Copy link
Member Author

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
Copy link
Member

tmat commented Jun 11, 2019

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

@clairernovotny
Copy link
Member Author

clairernovotny commented Jun 11, 2019

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.

image

@tmat
Copy link
Member

tmat commented Jun 11, 2019

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
Copy link
Member Author

clairernovotny commented Jun 11, 2019

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
Copy link
Member

tmat commented Jun 11, 2019

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
Copy link
Member

tmat commented Jun 11, 2019

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
Copy link
Member Author

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
Copy link
Member

tmat commented Jun 11, 2019

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
Copy link
Member Author

clairernovotny commented Jun 11, 2019

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
Copy link
Member

tmat commented Jun 11, 2019

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

@OmerRaviv
Copy link

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
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants