Debugging Flurl with pdb

[tranb3r]

I'm trying to step into Flurl code when debugging my app, but it does not work.
I've tested with newtonsoft.json and it works, so my visual studio is properly configured.
Could you please confirm that it should work ?
Is there any reason why pdb files are published in the nuget, instead of using nuget.org symbol server ? Maybe this is the reason why it doesn't work...

[tmenier]

Any additional details you can provide beyond "doesn't work"? PDBs were added for SourceLink support (#513). This isn't really my area of expertise to be honest, maybe @gitfool or @kroniak have thoughts?

[tranb3r]

"doesn't work" means:

• I'm trying to step into Flurl code during a debug session of my app, but nothing happens.
• when doing exactly the same thing with another package (for example newtonsoft.json), sourceLink does work as expected, so I'm pretty confident my setup is ok.

Of course I may have missed something, so it would be great if somebody could either confirm the issue or help me.

[gitfool]

@tranb3r I can successfully step debug into Flurl source with my repo at gitfool/BoardGameGeek.Dungeon.

If you want to give it a try, checkout and build the source, then with a breakpoint at Application/Services/BggService.cs#L136, you should be able to run a debug build and step into the FlurlClient.Request.

[tranb3r]

@gitfool Yes it works in your project. Thank you!

However it only works because of this file:
https://github.com/gitfool/BoardGameGeek.Dungeon/blob/master/Directory.Build.targets
And when adding this file to my project, it also works.

I'm ok with this workaround. But still, I'm wondering why we need it at all ?
Indeed, sourcelink works properly with newtonsoft.json package without the need for this file.
Is there a reason why pdb are embedded in the nuget, instead of using a symbol server ?

[gitfool]

@tranb3r Indeed I'm tired of waiting for a fix to dotnet/sdk#1458 (comment), which is only needed if embedding the symbols pdb in the nupkg. I recently looked at this yet again, and after reading dotnet/sdk#2679 (comment), I concluded that other options would be better; i.e. embed the symbols directly in the dll, as recommened but not available pre net472, or move them to a separate snupkg. I now think the latter would be the best option for Flurl so I opened a PR with the required changes. 😉

[tmenier]

@tranb3r @gitfool I've uploaded a prerelease and symbols package for Flurl only, not Flurl.Http (yet) for both Flurl and Flurl.Http:

https://www.nuget.org/packages/Flurl/3.0.6-pre1
https://www.nuget.org/packages/Flurl.Http/3.2.4-pre2

Could one or both of you test stepping into them? Thanks!

[tmenier]

BTW, the symbols are only published to nuget.org's symbol server, but I imagine that's the only place most people would expect them to live?

[tmenier]

I changed my mind (already) and published the Flurl.Http prerelease as well. I had it sitting here and figured why not. :) So go ahead and grab that instead if you want, just be sure and grab -pre2 and not -pre1; I neglected to to update the Flurl reference in -pre1.

https://www.nuget.org/packages/Flurl.Http/3.2.4-pre2

[tranb3r]

@tranb3r @gitfool I've uploaded a prerelease and symbols package for Flurl only, not Flurl.Http (yet) for both Flurl and Flurl.Http:

https://www.nuget.org/packages/Flurl/3.0.6-pre1 https://www.nuget.org/packages/Flurl.Http/3.2.4-pre2

Could one or both of you test stepping into them? Thanks!

I confirm it now works: I can step into the code for Flurl.Http 3.2.4-pre2.
Thank you @tmenier

[gitfool]

@tmenier works for me too, without the Directory.Build.targets hack and provided the NuGet.org Symbol Server is enabled.

[tmenier]

Great, thanks for confirming! I'll hopefully strip the -pre's and fully release today.

[tmenier]

A day later than planned, but this is fully released :)