web-dev-qa-db-ja.com

System.Net.Http NuGetパッケージ4.3.0リファレンスは、System.Diagnostics.DiagnosticSource ver4.0.0.0リファレンスでSystem.IO.FileLoadExceptionを生成します

問題の説明：

共有ライブラリ「shared.dll」プロジェクトは、System.Net.HttpNuGetパッケージ4.3.0を参照します。 「shared.dll」を参照するアプリケーションが失敗する

System.IO.FileLoadException

ファイルまたはアセンブリ 'System.Diagnostics.DiagnosticSource、Version = 4.0.0.0、Culture = neutral、PublicKeyToken = cc7b13ffcd2ddd51'またはその依存関係の1つを読み込めませんでした。見つかったアセンブリのマニフェスト定義がアセンブリ参照と一致しません。 （HRESULTからの例外：0x80131040）

system.Net.Http.WinHttpHandler.SendAsync（...）で

この問題を調査した結果、上記の失敗の原因は次のとおりです。

  • System.Net.Http v 4.3.0 のパッケージ情報ページには、 System.Diagnostics.DiagnosticSource v 4.3.0 以降への依存関係が記載されています。 。このパッケージは、System.Net.Http v4.3.0がプロジェクトから参照されるときに自動的にダウンロードされます。
  • System.Net.Http v 4.3.0のNuGetパッケージには、実際にはSystem.Net.Http.dll v 4.1.1.0が含まれています（2017年1月8日現在）。
  • System.Diagnostics.DiagnosticSource v 4.3.0のNuGetパッケージには、実際にはSystem.Diagnostics.DiagnosticSource v 4.0.1.0が含まれています（2017年1月8日現在）。
  • System.Net.Http ver4.1.1.0はSystem.Diagnostics.DiagnosticSourcev。4.0.0.0を参照します enter image description here
  • System.Diagnostics.DiagnosticSourcev。4.0.0.0は、ダウンロードしたdll v4.0.1.0と完全に一致するわけではありません。
  • 厳密に名前が付けられたライブラリ参照のバージョンが完全に一致しない場合でも、.NETランタイムは参照されているアセンブリを見つけようとします。できない場合：ライブラリロード例外が生成されます。次の 備考 も参照してください。

いくつかの回避策があります：

  1. app.configオプション：app.configの binding redirection を使用してany "shared.dll"-アプリケーションを参照しています。
<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. System.Diagnostics.DiagnosticSource.dllをバージョン4.0.0.0に強制する：System.Net.Httpを参照するプロジェクトにSystem.Diagnostics.DiagnosticSourcev。4.0.0.0へのNuGet参照を追加して、dllバージョン4.0.1.0の自動ダウンロードをプリエンプトします。このオプションを使用すると、NuGetの依存関係を自動的に更新する機能が失われますが、アプリケーションの展開は構成不要になります。

適切な問題の解決策は、パッケージの所有者による前述のNuGetパッケージの不整合を修正することにあるとはいえ、しつこい感じがあります。ソースで修正された場合、System.Net.Httpパッケージを消費するコードの回避策は必要ありません。

質問：

  1. 以前の正確なバージョンのパッケージ4.1.1があるのに、System.Net.Http v4.3.0パッケージに不一致のSystem.Net.Http.dllv 4.1.1が含まれているのはなぜですか？
  2. 上記の2つの回避策のいずれかを実行する必要がありますか？
  3. どちらがいいですか？
  4. または：問題に対する別の解決策はありますか？
  5. または：不整合を修正するNuGetパッケージの差し迫った更新はありますか？

ありがとう。

dllnuget-packagesystem.netfileloadexception.net-4.6.2
16
Serge Pavlov

答えの99％はすでにそこにあるので、私自身の質問に答えることは事実上正しいと思います。

Github/corefxの開発チームは、 この問題 解決は別の 既知の問題 System.Diagnostics.DiagnosticSourceへのハード参照を削除するという性質による修正の副作用であると認めました。 System.Net.Httpプロジェクトからのdll。

それまで：提供されている2つの回避策のいずれも、個人的な好みに基づいて使用できます。

4
Serge Pavlov

NuGetから System.Net.Http （バージョン4.3.1）をインストールしてこの問題を解決しました。

9
Oleksandr Fentsyk

私の場合、

FileLoadException：ファイルまたはアセンブリを読み込めませんでした 'System.Diagnostics.DiagnosticSource、Version = 4.0.3.0、Culture = neutral、Public KeyToken = cc7b13ffcd2ddd51'。見つかったアセンブリのマニフェスト定義がアセンブリ参照と一致しません。 （HRESULTからの例外：0x80131040）

asp.Net Core2.0プロジェクトにMicrosoft.AspNetCore.TestHostパッケージ「2.1.0-preview2-final」が追加されたときに開始されました。修正は、安定バージョン「2.0.2」をインストールすることでした

0
MiFreidgeim SO-stop being evil