Hi,

I am doing more research into this issue and, in trying to narrow down the root cause, I came upon this link:
dotnet/standard#481

I have a project (rather, a really big solution) that is using packages.config. I think (per the article) that binding redirects are turned on for my root application project (see image below).

Now, I have to take a visual studio solution with 200+ projects in it and somehow convert all of them to PackageReference. Oy.

I am going to try turning the Auto-generate binding redirects off first.

Since my solution is so big, and since Flurl.Http is a central dependency to this whole affair, I really am concerned about right-clicking 200 times to change my solution to PackageReference format (away from packages.config unless it is absolutely necessary.

So I am trying whatever I can think of, just short of that, first. I think it is when the FlurlClient constructor news up a HttpClient is the kicker. My project builds perfectly with the Flurl.Http NuGet package installed, but the error above comes up at runtime, as I've previously stated.

I imagine you've googled the error message and seen the sheer number of Stack Overflow questions and GitHub issues related to this. I'd even venture to guess most .NET developers have wasted multiple days on this one at some point in their career. :)

I don't recall the specifics of what I've done in the past. My best advice is read through the answers here, and if your goal is to fix it without widespread changes, then focus on just System.Net.Http, even if you have to type a binding redirect manually. That's where the problem is.

I'll keep this open as informational if you want to report your findings, but this isn't a Flurl bug, and I won't be able to help you any farther than what you'll find googling this.

Hi @tmenier

Thanks for the update. I actually solved it, and thankfully it did not take a huge amount of effort. Not thankfully -- as you yourself alluded to above -- it took me several weeks of Googling to figure this out. :-(

It turns out I only needed to change code in the App.config and the `.csproj file of the root project of my solution:

Also had to make the same changes in the App.config and the .csproj file of my Data service locator project (that houses my Entity Framework .edmx` model.

I then went to my C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\lib directory and renamed System.Net.Http.dll found there to System.Net.Http.dll.bak per a StackOverflow answer (I cannot remember where offhand). Basically, the thrust of the answer was to say that the System.Net.Http.dll value in the directory above is trying to be referenced by Visual Studio even though the Flurl and Flurl.Http NuGet packages refer to it internally -- Visual Studio keeps trying to copy the DLL from here anyway.

You have to rename the file in the net461 subdirectory, because that is the .NET Framework version upon which Flurl and Flurl.Http are written to depend upon.

Poof! The error disappeared. I am so glad I found an answer to my issue without having to right-click on all 200+ projects in my Solution and say Migrate packages.config to PackageReference -- that would have been such a pain!

Nice. Yes in my experience "less is more" when it comes to binding redirects. In other words, I've had better luck fixing problems by deleting them than by adding/changing them. Let the runtime figure it out. Glad you got to the bottom of it.