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

PDBs and source should be published on a source server #4683

Open
wixbot opened this issue Feb 22, 2015 · 8 comments
Open

PDBs and source should be published on a source server #4683

wixbot opened this issue Feb 22, 2015 · 8 comments

Comments

@wixbot
Copy link

wixbot commented Feb 22, 2015

The toolset PDBs should be available in an installer so we can more easily get detailed stack traces for bug reports. Either it should come standard in the WiX bundle or be available for milestone releases as a standalone .msi that installs itself wherever the core is installed. For reference, it's about 4MB cabbed for toolset and extension PDBs. See barnson/wix3@fee3e49.

Originally opened by barnson

@wixbot
Copy link
Author

wixbot commented Mar 3, 2015

Release changed from v3.10 to v3.x

@wixbot wixbot added this to the v3.x milestone Dec 20, 2015
@robmen robmen self-assigned this Mar 17, 2021
@robmen robmen modified the milestones: v3.x, v4.0 Mar 17, 2021
@rseanhall rseanhall added this to To do in wix.4.0-preview.1 Jun 14, 2021
@robmen robmen added the triage label Jan 5, 2022
@robmen robmen removed their assignment Jan 5, 2022
@robmen
Copy link
Member

robmen commented Jan 5, 2022

I've done some research into the current state of symbol servers and publishing to NuGet. It's not great.

  1. Where possible (modern managed code) we've standardized on embedding .pdbs into the built binaries. This reduces the .pdbs to handle (almost?) exclusively to native code (custom actions, burn, wixnative, etc).

  2. NuGet has standardized on a new symbol package format .snupkg. Unfortunately, it is important to note that .snupkgs only support "Portable PDBs" which means native code .pdbs are not supported:

    Native projects, such as C++ projects, produce Windows PDBs instead of Portable PDBs. These are not supported by NuGet.org's symbol server. Please use Legacy Symbol Packages instead.

    We do currently package up our native .pdbs in .snupkgs because that is the mechanism that works properly with the Pack target. It captures only the .pdbs in the .snupkg while packaging .nupkgs for each project. Unsurprisingly, the NuGet server rejects our current .snupkgs (it allows the upload but fails during a later verification process).

  3. Legacy symbol packages are the proposed solution for native .pdbs. The documentation references https://nuget.smbsrc.net as the symbol store for legacy packages. Unfortunately, nuget.smbsrc.net has fallen into disrepair and appears abandoned.

That means having a symbol server requires a custom solution. While that is a somewhat interesting project, the focus is on finishing v4.0. So, two proposals come to mind:

  1. The .snupkgs are uploaded every build with all of the other .nupkgs as build artifacts. Therefore if we archive the build artifacts (as was done in v4.0-preview.0) then the symbols are available. However, they are not trivial to acquire as you have to the correct .snupkg to get the required .pdbs.

  2. We could abandon the use of .snupkgs (since they aren't really .snupkgs given native .pdbs are contained) and zip up all of the .pdbs to be included as a single "debug.zip" in the build artifacts. This isn't much different than option 1 but makes it (somewhat) easier to get the .pdbs.

Or maybe there is yet a better option that fits in the v4.0 timeframe.

@barnson
Copy link
Member

barnson commented Jan 5, 2022

#2: +1

Without "modern" magic, we still need a way to deliver and consume matching source.

@rseanhall
Copy link
Contributor

This probably falls into your custom solution category, but the source code for (what used to be) https://nuget.snbsrc.net is at https://github.com/SymbolSource/SymbolSource. If someone gives me access to a server, I could spend some time trying to setup that project so we would have our own symbol server for native PDBs. That should have the magic technology where you just point VS to that server and you don't have to worry about PDBs and source code.

@robmen
Copy link
Member

robmen commented Jan 5, 2022

Yeah, that code is more than what we'd need. If you want to build a custom solution, take a look at how: https://github.com/SeanCline/PythonSymbols or, we could use Azure blob hosting with a redirect in front like: https://github.com/electron/symbol-server

@rseanhall
Copy link
Contributor

The solution would need to do the source code magic as well if I'm going to spend time on it. It isn't clear to me whether those projects do that.

@robmen
Copy link
Member

robmen commented Jan 5, 2022

My understanding is that the "source code magic" is just another executable. This gist was a nice read. However, I thought that SourceLink (.nupkg) already did the work to tie the source code path to the .pdb but I could definitely be mistaken about it. I've not delved much deeper than this plus my memory from time at MSFT.

@rseanhall
Copy link
Contributor

I had researched this when I setup all those symbol packages over a year ago, and thought that the way to do it was to create the legacy symbols .nupkg, which embedded the source files I think, with that SymbolSource project. I didn't realize that SourceLink had basically replaced the requirement to embed the source files in the .nupkg, so I think SourceLink and .nupkg are completely separate things. In that case, we probably should just create a .zip with all the .pdbs and maybe later someone can create a build step to also push them to our own symbol server.

@barnson barnson removed this from To do in wix.4.0-preview.1 Jan 13, 2022
@barnson barnson modified the milestones: v4.0, v4.x Jan 13, 2022
@barnson barnson removed the triage label Jan 13, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants