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

Add SourceLink support #513

Closed
gitfool opened this issue May 3, 2020 · 4 comments · Fixed by #514
Closed

Add SourceLink support #513

gitfool opened this issue May 3, 2020 · 4 comments · Fixed by #514

Comments

@gitfool
Copy link
Contributor

gitfool commented May 3, 2020

SourceLink is standard now and would make it easy to debug code using this awesome package!

@tmenier
Copy link
Owner

tmenier commented Oct 1, 2020

Ready in prerelease 5: https://www.nuget.org/packages/Flurl.Http/3.0.0-pre5

@tmenier
Copy link
Owner

tmenier commented May 27, 2022

@gitfool Do we still need SourceLink/embedded PDBs now that symbols packages are being published? If it's effectively 2 ways to do the same thing then I'd really like to undo this. The most popular request for 4.0 is removing Newtonsoft in favor of System.Text.Json, and a reason often cited is to reduce Flurl's footprint in things like Blazor and Xamarin apps. PDBs and the SourceLink dependency add to that footprint too, maybe not as much but people are quite sensitive about it and my goal is to keep the package as small and dependency-free as possible.

Basically I'm proposing we undo most of #514. Thoughts?

@gitfool
Copy link
Contributor Author

gitfool commented May 27, 2022

You don't need to worry about that and shouldn't change anything. SourceLink is still configured and points back to the GitHub repository. This keeps the symbols fairly small plus the symbols are now in a separate NuGet package, so should only be downloaded on demand. Note the differences in the NuGet packages before and after the snupkg change.

Flurl.Http.nupkg (3.2.3):
image

Flurl.Http.nupkg (3.2.4):
image

Flurl.Http.snupkg (3.2.4):
image

FWIW, adding another target for .NET 5.0/6.0 might be a good option; .NET 6.0 especially since it's an LTS release, replaces .NET Standard, and may have fewer package dependencies.

@tmenier
Copy link
Owner

tmenier commented May 27, 2022

Thanks for the quick response, I'll go forward without worrying about it.

Good point about a 6.0 target. Very relevant too - it appears the netstandard2.0 target will require the System.Text.Json NuGet package, which won't make those wanting a smaller footprint particularly happy! (I'll skip 5.0 since it's out of support already.)

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

Successfully merging a pull request may close this issue.

2 participants