System.IO.FileNotFoundException: Could not load file or assembly 'System.Net.Http, Version=4.2.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.

[astrohart]

I am utilizing the Coinbase project by Brian Chavez @bchavez, which itself depends on Flurl and Flurl.Http.

I am 100% sure I have the very latest NuGet packages installed and my solution builds; however, in my logs I am seeing:

2021-02-04 10:10:01,041 ERROR - System.IO.FileNotFoundException: Could not load file or assembly 'System.Net.Http, Version=4.2.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.
	   at Flurl.Http.FlurlClient..ctor(String baseUrl)
   at Coinbase.CoinbaseClient..ctor(Config config)

I am completely baffled what is the root cause of this error. I have forked this repo and cloned it to my local machine for testing purposes. I also have deleted the .git and github folders in the clone, out of an abundance of caution. I do not want to accidently screw up the remote until I am 100% sure of the cause.

Request permission to do some digging and then post more info on this comment thread. Perhaps I may even be able to submit a PR. However, my plan for the moment is to add the Flurl and Flurl.Http projects to my solution and fill the source code with extra log4net calls to try and track down the culprit.

Will post to this thread when I know more.

[astrohart]

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.

[astrohart]

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.

[tmenier]

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.

[astrohart]

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!

[tmenier]

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.