title: System.Net.Http NuGet package 4.3.0 reference generates System.IO.FileLoadException on System.Diagnostics.DiagnosticSource ver 4.0.0.0 reference
body: <p>Description of the problem:</p>
  
  <p>A shared library "shared.dll" project references System.Net.Http NuGet package 4.3.0. The application that references "shared.dll" fails with</p>
  
  <blockquote>
    <p>System.IO.FileLoadException</p>
    
    <p>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)</p>
    
    <p>at System.Net.Http.WinHttpHandler.SendAsync(...)</p>
  </blockquote>
  
  <p>After investigating this issue we came to the following cause for the above failure:</p>
  
  <ul>
  <li>The package information page for <a href="https://www.nuget.org/packages/System.Net.Http/4.3.0" rel="noreferrer">System.Net.Http v 4.3.0</a> states dependency on <a href="https://www.nuget.org/packages/System.Diagnostics.DiagnosticSource/" rel="noreferrer">System.Diagnostics.DiagnosticSource v 4.3.0</a> or above. This package is automatically downloaded when System.Net.Http v 4.3.0 is referenced from the project.</li>
  <li>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).</li>
  <li>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).</li>
  <li>System.Net.Http ver 4.1.1.0 references System.Diagnostics.DiagnosticSource v. 4.0.0.0
  <a href="https://i.stack.imgur.com/9nWum.jpg" rel="noreferrer"><img src="https://i.stack.imgur.com/9nWum.jpg" alt="enter image description here"></a></li>
  <li>System.Diagnostics.DiagnosticSource v. 4.0.0.0 is not an exact match to v the downloaded dll v 4.0.1.0.</li>
  <li>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 <a href="https://msdn.microsoft.com/en-us/library/eftw1fys(v=vs.110).aspx" rel="noreferrer">remark</a></li>
  </ul>
  
  <p>There are couple workarounds:</p>
  
  <ol>
  <li>app.config option: Declare compatible versions (how far should we go with that?) with <a href="https://msdn.microsoft.com/en-us/library/eftw1fys(v=vs.110).aspx" rel="noreferrer">binding redirection</a> in app.config for <em>any</em> "shared.dll" - referencing application.</li>
  </ol>
  
  <blockquote>
  <pre><code>&lt;assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"&gt;
    &lt;dependentAssembly&gt;
      &lt;assemblyIdentity name="System.Diagnostics.DiagnosticSource" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral" /&gt;
      &lt;bindingRedirect oldVersion="0.0.0.0-4.0.1.0" newVersion="4.0.1.0" /&gt;
    &lt;/dependentAssembly&gt;
  &lt;/assemblyBinding&gt;
  </code></pre>
  </blockquote>
  
  <ol start="2">
  <li>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.</li>
  </ol>
  
  <p>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.</p>
  
  <p>Questions: </p>
  
  <ol>
  <li>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?</li>
  <li>Should we go ahead with any of 2 workarounds mentioned above?</li>
  <li>Which one is better?</li>
  <li>Or: Is there another solution to the problem?</li>
  <li>Or: Is there an imminent update to the NuGet packages that fixes the inconsistency?</li>
  </ol>
  
  <p>Thanks.</p>