System.Net.Http NuGet package 4.3.0 reference generates System.IO.FileLoadException on System.Diagnostics.DiagnosticSource ver 4.0.0.0 reference

Question

Description of the problem:

A shared library "shared.dll" project references System.Net.Http NuGet package 4.3.0. The application that references "shared.dll" fails with

System.IO.FileLoadException

Could not load file or assembly 'System.Diagnostics.DiagnosticSource, Version=4.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

at System.Net.Http.WinHttpHandler.SendAsync(...)

After investigating this issue we came to the following cause for the above failure:

• The package information page for System.Net.Http v 4.3.0 states dependency on System.Diagnostics.DiagnosticSource v 4.3.0 or above. This package is automatically downloaded when System.Net.Http v 4.3.0 is referenced from the project.
• NuGet package of System.Net.Http v 4.3.0 in fact includes System.Net.Http.dll v 4.1.1.0 (as of Jan 8 2017).
• NuGet package of System.Diagnostics.DiagnosticSource v 4.3.0 in fact includes System.Diagnostics.DiagnosticSource v 4.0.1.0 (as of Jan 8 2017).
• System.Net.Http ver 4.1.1.0 references System.Diagnostics.DiagnosticSource v. 4.0.0.0
• System.Diagnostics.DiagnosticSource v. 4.0.0.0 is not an exact match to v the downloaded dll v 4.0.1.0.
• When the version of a strongly-named library reference is not in exact match, .NET run time still tries to find the referenced assembly. If it can't: the library load exception is generated. Also see the following remark

There are couple workarounds:

1. app.config option: Declare compatible versions (how far should we go with that?) with binding redirection in app.config for any "shared.dll" - referencing application.

<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
  <dependentAssembly>
    <assemblyIdentity name="System.Diagnostics.DiagnosticSource" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-4.0.1.0" newVersion="4.0.1.0" />
  </dependentAssembly>
</assemblyBinding>

2. Force System.Diagnostics.DiagnosticSource.dll to version 4.0.0.0: Add NuGet reference to System.Diagnostics.DiagnosticSource v. 4.0.0.0 to the projects referencing System.Net.Http to preempt automatic download of dll version 4.0.1.0. This option looses ability to automatically update the NuGet dependency, but makes deployment of the applications configuration-less.

There is a nagging feeling though that the proper issue solution lies in fixing the aforementioned NuGet packages inconsistencies by the package's owners. When fixed at the source, no workaround for System.Net.Http package consuming code would be required.

Questions:

1. Why System.Net.Http v 4.3.0 package contains mismatching System.Net.Http.dll v 4.1.1 while there is earlier exact version package 4.1.1?
2. Should we go ahead with any of 2 workarounds mentioned above?
3. Which one is better?
4. Or: Is there another solution to the problem?
5. Or: Is there an imminent update to the NuGet packages that fixes the inconsistency?

Thanks.

Answer 1

Neither assembly binding redirects nor adding a reference to System.Net.Http worked for me. I have no idea why. What ultimately did work for me was to remove the version specification and specify a HintPath directly to the DLL. So, I went from this:

<Reference Include="System.Diagnostics.DiagnosticSource, Version=6.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51, processorArchitecture=MSIL">

to this:

<Reference Include="System.Diagnostics.DiagnosticSource, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51, processorArchitecture=MSIL">
  <HintPath>..\packages\System.Diagnostics.DiagnosticSource.6.0.0\lib\net461\System.Diagnostics.DiagnosticSource.dll</HintPath>
  <Private>True</Private>
</Reference>

and that seems to have done the trick. I don't like losing the direct version reference, but there didn't seem to be any other way.

Answer 2

In my case the

FileLoadException: Could not load file or assembl y 'System.Diagnostics.DiagnosticSource, Version=4.0.3.0, Culture=neutral, Public KeyToken=cc7b13ffcd2ddd51'. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

started when to Asp.Net Core 2.0 project was added Microsoft.AspNetCore.TestHost package "2.1.0-preview2-final". The fix was to install the stable version "2.0.2"

Answer 3

I solved this problem installing System.Net.Http (version 4.3.1) from NuGet.

Answer 4

I feel it would be factually correct to answer my own question because 99% of the the answer is already there.

The development team at github/corefx acknowledged this issue resolution would be a side effect of another known issue fix by the nature of removing the hard reference to System.Diagnostics.DiagnosticSource.dll from System.Net.Http project.

Until then: any of two provided workarounds is OK to use based on personal preferences.