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

13

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 enter image description here
  • 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>
  1. 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.

dll
nuget-package
system.net
fileloadexception
.net-4.6.2
asked on Stack Overflow Jan 9, 2017 by Serge Pavlov • edited Jan 10, 2017 by Serge Pavlov

3 Answers

5

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

answered on Stack Overflow Apr 7, 2017 by Oleksandr Fentsyk • edited Apr 10, 2017 by Oleksandr Fentsyk
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.

answered on Stack Overflow Jan 10, 2017 by Serge Pavlov • edited Jan 11, 2017 by Serge Pavlov
0

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"

answered on Stack Overflow May 9, 2018 by Michael Freidgeim

User contributions licensed under CC BY-SA 3.0