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.

Prow

I tried installing System.Net.Http 4.3.0 on a .NET Framework 4.6 project and that binding redirect was automatically generated. Try asking this question on the dotnet/corefx GitHub issue tracker for more details. – Grory

Thanks, I am going to ask through GitHub. I did try removing and re-adding the reference (VS 20015) and the app.config stayed unchanged (no binding redirect). Note that our solution is more complex than single assembly solution. It includes multiple executable and shared library assemblies under one roof. – Prow

@Joel Verhagen: Opened ticket at github.com/dotnet/corefx/issues/15031 – Prow

Answer 1

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.

Prow

Thanks for saving my day. Am i correct if this issue is created just by incorrect metadata in microsoft's packages (implying it should not be that hard to fix)? – Soap

In my opinion it is a by design behavior (the strongly typed assembly design) – Prow

Answer 2

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

Delft

Took me 2 days of research and trying different settings for oldVersion -> newVersion to come to the same conclusion and only afterwards finding the solution here. – Glove

Answer 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"

Liripipe

Answer 4

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.

Sandpaper