The problem you're facing is related to Visual Studio, especially 2017 which is shipped with System.Net.Http v4.2.0.0
. However, adopting the new way whereby any references should be done via NuGet, latest version of System.Net.Http
which is 4.3.3 contains the dll version 4.1.1.2.
The problem is that VS at build time and at run time as well will ignore your reference and it will try to reference the DLL it knows about.
How to fix it:
c:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\lib\
); if you've got a different version then the path will slightly differ, not much thoughRuntime errors: add an assembly binding redirect
If you look online on google you'll find a few open issues with Microsoft about this, so hopefully they'll fix this in the future.
Hope this helps.
Update:
When looking at finding some permanent fixes for this issue to work on the build agents, noticed that if you migrate to the new NuGet PackageReference model (in .csproj
not in packages.config
) tends to work better. Here's a link to the guide on how to do this upgrade: https://docs.microsoft.com/en-us/nuget/reference/migrate-packages-config-to-package-reference
Removing binding redirect worked for me, you can try removing it:
<bindingRedirect oldVersion="0.0.0.0-4.2.0.0" newVersion="4.2.0.0" />
An addition to the answer @AndreiU already gave and how to reproduce runtime errors locally.
I got the runtime error below when deploying to Azure, not locally.
{"Message":"An error has occurred.","ExceptionMessage":"An error occurred when trying to create a controller of type 'OrderController'. Make sure that the controller has a parameterless public constructor.","ExceptionType":"System.InvalidOperationException","StackTrace":" at System.Web.Http.Dispatcher.DefaultHttpControllerActivator.Create(HttpRequestMessage request, HttpControllerDescriptor controllerDescriptor, Type controllerType)\r\n at System.Web.Http.Controllers.HttpControllerDescriptor.CreateController(HttpRequestMessage request)\r\n at System.Web.Http.Dispatcher.HttpControllerDispatcher.d__1.MoveNext()","InnerException":{"Message":"An error has occurred.","ExceptionMessage":"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.","ExceptionType":"System.IO.FileNotFoundException","StackTrace":" at Company.Project.Service.CompanyIntegrationApiService..ctor(Uri baseAddress)\r\n at Company.Project.BackOffice.Web.Controllers.OrderController..ctor() in C:\projects\company-project\src\Company.Project.BackOffice.Web\Controllers\Order\OrderController.cs:line 30\r\n at lambda_method(Closure )\r\n at System.Web.Http.Dispatcher.DefaultHttpControllerActivator.Create(HttpRequestMessage request, HttpControllerDescriptor controllerDescriptor, Type controllerType)"}}
When I started looking at assemblies I could see that my web project and service project targeted different versions for System.Net.Http
.
Web project:
Service project:
It's easy to think that this is caused by a mismatch in versions but the key here is to look at the error The system cannot find the file specified.
.
Looking at the path property we can see that the web project targets a .Net Framework assembly while the service targets an assembly from Visual Studio 2017. Since the server does not have Visual Studio 2017 installed, the runtime error will occur.
Web path:
C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.6.1\System.Net.Http.dll
Service path:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\lib\System.Net.Http.dll
Something as simple as setting Copy Local
to true
can fix the problem, however not in all cases.
In order to reproduce the error on your local machine, simply remove the needed System.Net.Http.dll
from the Visual Studio specific folder. This will will give you the runtime error and probably some build errors. After these are fixed everything should work, at least it did for me.
If you have installed System.Net.Http
via NuGet
check which assembly is used by looking at the .csproj
version. System.Net.Http 4.3.4
gives the following assembly for example:
<Reference Include="System.Net.Http, Version=4.1.1.3, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL">
<HintPath>..\packages\System.Net.Http.4.3.4\lib\net46\System.Net.Http.dll</HintPath>
<Private>True</Private>
</Reference>
If you use a build server like Jenkins, TeamCity or AppVeyor the runtime missing .dll
might exist there as well. In this case it might not help to use NuGet version of System.Net.Http or deleting the missing .dll
locally. To solve this error look at the version that is not found and the specific PublicKeyToken
. After that create a binding redirect in either Web.config
or App.config
depending on your project. In my case I would like to use 4.0.0.0 instead:
<dependentAssembly>
<assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-4.2.0.0" newVersion="4.0.0.0" />
</dependentAssembly>
A good Github thread about the issue:
https://github.com/dotnet/corefx/issues/22781
I just installed System.Net.Http
using NuGet. You can grab it here:
https://www.nuget.org/packages/System.Net.Http/
The ASP.NET MVC
project I'm working on targets .NET 4.6.1
. It works perfectly on my machine while debugging in IIS Express
with Visual Studio 2019.
The problem happened when trying to run the application deployed to Azure. I was getting this error:
Could not load file or assembly 'System.Net.Http, Version=4.2.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies.
What really worked in my case was opening the .csproj file and searching for System.Net.Http
like in the following screenshot...
See that the .csproj
file has the version 4.1.1.3
:
<Reference Include="System.Net.Http, Version=4.1.1.3, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL">
The <HintPath>
actually points to the ..\packages
folder from Nuget, that is, this is the real version installed by Nuget. Once deployed this specific version will also be restored on the server side and everything should work with a bind redirect.
... and so the binding redirect should mention this specific version in Web.config
like this:
<dependentAssembly>
<assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-4.2.0.0" newVersion="4.1.1.3" />
</dependentAssembly>
This fixed the problem in my case after a couple of commits to Azure Kudu. The Azure web site finally started with no errors.
What I did to fix the issue was removed all the bindings from the web.config and did a
Update-Package -reinstall
This removed a bunch of the old bindings that probably do not need to be there and actually did a good cleaning.
I encountered this error when I deployed a web service to one of our servers. The project targeted .Net framework 4.7.2, which wasn't installed on the server. Installing the 4.7.2 framework on the server corrected the problem.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With