10

The project I'm working on has System.Net.Http version 4.3.3 installed, according to NuGet. It had a binding redirect in the Web.config file to redirect it to version 4.2.0.0, which worked for some reason:

<dependentAssembly>
    <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-4.2.0.0" newVersion="4.2.0.0" />
</dependentAssembly>

I changed it to point to 4.3.3.0 which is the version NuGet says is installed:

<dependentAssembly>
    <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-4.3.3.0" newVersion="4.3.3.0" />
</dependentAssembly>

... but now I get this error when I try to debug the ASP.NET site:

Could not load file or assembly 'System.Net.Http' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

=== Pre-bind state information ===
LOG: DisplayName = System.Net.Http
 (Partial)
WRN: Partial binding information was supplied for an assembly:
WRN: Assembly Name: System.Net.Http | Domain ID: 2
WRN: A partial bind occurs when only part of the assembly display name is provided.
WRN: This might result in the binder loading an incorrect assembly.
WRN: It is recommended to provide a fully specified textual identity for the assembly,
WRN: that consists of the simple name, version, culture, and public key token.
WRN: See whitepaper http://go.microsoft.com/fwlink/?LinkId=109270 for more information and common solutions to this issue.
LOG: Appbase = file:///C:/.../Dev/Src/Web/PortalSite/
LOG: Initial PrivatePath = C:\...\Dev\Src\Web\PortalSite\bin
Calling assembly : (Unknown).
===
LOG: This bind starts in default load context.
LOG: Using application configuration file: C:\...\Dev\Src\Web\PortalSite\web.config
LOG: Using host configuration file: C:\...\Documents\IISExpress\config\aspnet.config
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework\v4.0.30319\config\machine.config.
LOG: Policy not being applied to reference at this time (private, custom, partial, or location-based assembly bind).
LOG: Attempting download of new URL file:///C:/.../AppData/Local/Temp/Temporary ASP.NET Files/vs/e31848dc/3694ba06/System.Net.Http.DLL.
LOG: Attempting download of new URL file:///C:/.../AppData/Local/Temp/Temporary ASP.NET Files/vs/e31848dc/3694ba06/System.Net.Http/System.Net.Http.DLL.
LOG: Attempting download of new URL file:///C:/.../Dev/Src/Web/PortalSite/bin/System.Net.Http.DLL.
LOG: Using application configuration file: C:\...\Dev\Src\Web\PortalSite\web.config
LOG: Using host configuration file: C:\...\Documents\IISExpress\config\aspnet.config
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework\v4.0.30319\config\machine.config.
LOG: Redirect found in application configuration file: 4.2.0.0 redirected to 4.3.3.0.
LOG: Post-policy reference: System.Net.Http, Version=4.3.3.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
LOG: Attempting download of new URL file:///C:/.../AppData/Local/Temp/Temporary ASP.NET Files/vs/e31848dc/3694ba06/System.Net.Http.DLL.
LOG: Attempting download of new URL file:///C:/.../AppData/Local/Temp/Temporary ASP.NET Files/vs/e31848dc/3694ba06/System.Net.Http/System.Net.Http.DLL.
LOG: Attempting download of new URL file:///C:/.../Dev/Src/Web/PortalSite/bin/System.Net.Http.DLL.
WRN: Comparing the assembly name resulted in the mismatch: Minor Version
ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated.

To make things even more confusing, the DLL version in the bin directory for the site seems to be different again:

PS C:\...\Dev\Src\Web\PortalSite\bin> (Get-Item ...\bin\Debug\System.Net.Http.dll).VersionInfo

ProductVersion   FileVersion      FileName
--------------   -----------      --------
4.6.25908.02 ... 4.6.25908.02     C:\...\Dev\Src\Web\PortalSite\bin\System.Net.Http.dll

What's up with this? How did the redirect work before, and why doesn't it work now?

Jez
  • 27,951
  • 32
  • 136
  • 233
  • 1
    do not use any bindingRedirect for System.Net.Http , remove from config file and do not think witch version is in use, this is managed by your system – Mahdi Jul 22 '20 at 09:42

6 Answers6

12

do not use any bindingRedirect for System.Net.Http , remove from config file and do not think witch version is in use, this is managed by your system

i found that adding it to config file cause serious problem, because each file use diffrent version of this dll.

REMOVING System.Net.Http FROM CONFIG resolve my insane problem that cause errors and not found assembly .

Mahdi
  • 649
  • 8
  • 18
  • Thanks so much, after upgrading a web project from 4.7.1 to 4.7.2 I also upgraded the test project for it. It still had a bindingRedirect for System.Net.Http and when loading the web assembly in order to fake ResourceManager, it was crashing with another error that I should not load reference assemblies...but after removing the binding redirect, my test project works fine!!! – iBobb Feb 12 '21 at 17:24
7

It turns out that the DLL version in my bin directory was actually version 4.2.0.0, which is apparently bundled with Visual Studio 2017, and the version distributed in NuGet package version 4.3.3 is DLL version 4.1.1.2, which wasn't being used at all. Confusing! But this explains why the redirect to DLL version 4.2.0.0 worked and redirecting to 4.3.0.0 didn't.

Jez
  • 27,951
  • 32
  • 136
  • 233
0

I had similar issue in past. Most probably you have other assemblies in your .csproj which still have dependency on old version i.e. 4.2.0.0

rahulaga-msft
  • 3,964
  • 6
  • 26
  • 44
  • But why doesn't the binding redirect that to 4.3.3.0? – Jez Mar 05 '18 at 18:31
  • what version of dll is in your o/p directory ? – rahulaga-msft Mar 05 '18 at 18:33
  • if your o/p directory have 4.2 then how can you redirect it to 4.3 ? Redirect only says - _"dear CLR at runtime if you are asked to load 4.3, please load 4.2 because that is what i am making you available"_ – rahulaga-msft Mar 05 '18 at 18:35
  • What is an o/p directory? – Jez Mar 05 '18 at 18:41
  • Best thing to nail down issue i would suggest to use process explorer and see from where that dll is loaded. I am saying so because we kind of had similar issue where it was loading dll from GAC – rahulaga-msft Mar 05 '18 at 18:42
  • o/p directory i meant bin/debug or bin/release depending upon your build mode – rahulaga-msft Mar 05 '18 at 18:42
  • I did the Process Explorer thing, and iisexpress.exe doesn't have any version of `System.net.Http` loaded; `devenv.exe` has a bunch of different versions loaded. – Jez Mar 05 '18 at 18:49
  • devenv.exe is for visual studio. but btwn did you checked dll version in your bin directory after clean build ? – rahulaga-msft Mar 05 '18 at 18:54
  • The version in the bin directory after a clean build is `4.6.25908.02`. – Jez Mar 05 '18 at 19:08
  • I assume `4.6.25908.02` is not file or nuget package version. so if that is the case then how can you expect binding redirect to work. because you asking clr to load 4.3 which is not present. You might want to check from where `4.6.25908.02` is coming (**again assuming its actual dll version and not file version**) – rahulaga-msft Mar 05 '18 at 19:12
  • As I said in my question, somehow the original redirect to `4.2.0.0` was working. – Jez Mar 05 '18 at 19:21
  • How do you get the "actual DLL version"? – Jez Mar 05 '18 at 19:22
  • I use ILSPY or just decompile. But i am sure you can even use ILDASM to open dll to see assembly version. – rahulaga-msft Mar 05 '18 at 19:23
  • Let us [continue this discussion in chat](https://chat.stackoverflow.com/rooms/166269/discussion-between-rahul-agarwal-and-jez). – rahulaga-msft Mar 05 '18 at 19:28
  • cool :) now you need to check why o/p directory still have 4.2 even though you installed 4.3. Probably other .csproj still have reference to old one and when you build, it copied from there – rahulaga-msft Mar 05 '18 at 19:32
0

Ya exactly. The nuget versions and the dll's assembly versions are different. Make sure you understand the difference clearly.

A nuget package maybe 4.1.1 and the assembly version of the dlls inside it needn't be 4.1.1 or anything related to 4.1.1.

We specify dll versions in all the dll references. And nuget references are made so that once the project is building, the required dlls are made available in the packages, so that it can be taken and moved to the local bin for the compiler to use.

Adarsh P. S.
  • 21
  • 5
0

You can also change the newVersion to the version that exists currently in your project:

  1. search for System.Net.Http string in Search solution Explorer inside VS and find the version of this assembly by checking property of that dll or reference by checking property window(f4)

  2. change the newVersion to the one that exists in your project. for example 4.4

     <bindingRedirect oldVersion="0.0.0.0-4.3.3.0"  newVersion="4.4"  />

sometimes removing the whole depencency like the answer by @Mahdi helps https://stackoverflow.com/a/63031440/184572

Iman
  • 17,932
  • 6
  • 80
  • 90
0

I think they changed the publicKeyToken between versions for this dll because this does not work:

<dependentAssembly>
<assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-4.3.4.0" newVersion="4.3.4.0" />
</dependentAssembly>

But this works:

  <dependentAssembly>
    <assemblyIdentity name="System.Net.Http"culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-4.3.4.0" newVersion="4.3.4.0" />
  </dependentAssembly>
Markus
  • 1,020
  • 14
  • 18