tmenier / Flurl

Fluent URL builder and testable HTTP client for .NET

Home Page:https://flurl.dev

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

upgrade to Flurl 4.x but keep Flurl.Http at <4

springy76 opened this issue · comments

Is this a supported scenario or will I get random method-not-found exceptions at runtime?

Would it be possible to create a (nuget) build ("branch") of Flurl.Http (maybe 3.3.x) which would reference the newest Flurl 4.x package so it would be more clear that it's compatible (if at all)?

What's the motivation for updating just Flurl and not Flurl.Http?

I wan't to reduce the amount of "old" packages as much as possible. While I also would like to update Flurl.Http this step will require a huge amount of time (I currently don't have) for changes and thorough testing due to the many breaking changes - not speaking of getting rid of Newtonsoft.Json which will require even more work (for all the data models, might be easier with STJ 8.0 now) but can be postponed using the migration package, but this also has to be initialized for all dependent projects, so Flurl.Http 3.x will be used more longer than I wish to.

If you really want to upgrade just Flurl, try it and see if anything breaks. I don't see any compelling reason to do it until you're ready to upgrade both though. They're meant to go hand in hand, so I don't plan on supporting this in any official capacity or doing further enhancements to 3.x. I just don't see a good enough reason for me to spend time on that. Sorry.

Side note: did you read the upgrade guide? There's a Newtonsoft companion lib to ease that part of the upgrade.

The upgrade guide is why I know the transition to v4 will take a huge amount of time. With "migration package" I meant the "Newtonsoft companion lib" because getting away from Newtonsoft is another big deal, alone due to the fact STJ ignores DataMemberAttributes.

I can update Flurl alone to 4x and it seems as it works well - but a MethodNotFoundException might occur at any place at any time. NuGet (transitive) dependency hell is no better than DLL hell, ex: https://stackoverflow.com/questions/77098132/error-generating-jwt-token-during-asp-net-core-web-api-authorization/77133355#comment136008891_77133355

Your options seem clear: upgrade just Flurl and take your chances, or don't until you're ready to upgrade both. I recommend the latter. I don't see any practical value in what you requested.