System.Net.Http NuGet package 4.3.0 reference gene

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:

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>

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:

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?
Should we go ahead with any of 2 workarounds mentioned above?
Which one is better?
Or: Is there another solution to the problem?
Or: Is there an imminent update to the NuGet packages that fixes the inconsistency?

Thanks.

回答1:

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

回答2:

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.

回答3:

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"