System.Net.Http 4.2.0.0の奇妙な問題が見つかりません

私は奇妙な問題を抱えています。

Cosmos DBに関連する機能のラッパークラスを備えた単純なクラスライブラリプロジェクト（完全な.NET Framework、4.6.1）があります。したがって、このプロジェクトに「Microsoft.Azure.DocumentDB」NuGetパッケージ1.19.1を追加しました。それ以外に、「Newtonsoft.Json」NuGetパッケージ10.0.3と、いくつかの「Microsoft.Diagnostics.EventFlow。*」NuGetパッケージへの参照があります。

これまでのところ、すべてがエラーなしでコンパイルされます。

しかし、ラッパークラス（単純なService Fabricステートレスサービス（完全な.NET Framework 4.6.1）から消費）に到達したらすぐに、次のコード行を実行してみます。

_docClient = new DocumentClient(new Uri(cosmosDbEndpointUrl), cosmosDbAuthKey);

実行時にこの奇妙なエラーが発生します：

System.IO.FileNotFoundException occurred HResult = 0x80070002
Message = Could not load file or assembly 'System.Net.Http、Version = 4.2.0.0、Culture = neutral、PublicKeyToken = b03f5f7f11d50a3a'またはその依存関係の1つ。システムは、指定されたファイルを見つけることができません。
Source = StackTrace：at Microsoft.Azure.Documents.Client.DocumentClient.Initialize（Uri serviceEndpoint、ConnectionPolicy connectionPolicy、Nullable 1 desiredConsistencyLevel) at Microsoft.Azure.Documents.Client.DocumentClient..ctor(Uri serviceEndpoint, String authKeyOrResourceToken, ConnectionPolicy connectionPolicy, Nullable1 desiredConsistencyLevel）

内部例外1：FileNotFoundException：ファイルまたはアセンブリ 'System.Net.Http、Version = 4.0.0.0、Culture = neutral、PublicKeyToken = b03f5f7f11d50a3a'またはその依存関係の1つを読み込めませんでした。システムは、指定されたファイルを見つけることができません。

System.Net.Httpアセンブリがまったく見つからない理由はまったくわかりません。クラスライブラリプロジェクトに、.Net Frameworkアセンブリ「System.Net.Http 4.0.0.0」へのアセンブリ参照さえあります。

私も理解していないのは、この変なバインディングリダイレクトが4.2.0.0にあるということです。これを回避するために、Service Fabricサービス（クラスライブラリを使用している）のapp.configに次のリダイレクトを追加しようとしました。

しかし、それでも違いはありません。実行時にエラーが発生します。

誰か手がかりがありますか？誰かがそのような問題を見たことがありますか？

よろしくお願いします、OliverB

あなたが直面している問題はVisual Studio、特にに同梱されてSystem.Net.Http v4.2.0.0いる2017に関連しています。ただし、すべての参照をNuGet経由で行う必要がある新しい方法を採用しています。最新バージョンSystem.Net.Httpは4.3.3で、dllバージョン4.1.1.2が含まれています。

問題は、ビルド時と実行時のVSがユーザーの参照を無視し、既知のDLLを参照しようとすることです。

修正方法：

• System.Net.Httpへの参照がすべてNuGet経由で行われることを確認してください
• ビルド時のエラー： VS 2017に同梱されているSystem.Net.Http.dllの拡張子を変更します（または他の場所に移動します...基本的には削除しc:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\lib\ます）。別のバージョンを持っている場合、パスはわずかに異なりますが、それほどではありません

• ランタイムエラー：アセンブリバインディングリダイレクトを追加する

Googleでオンラインを見ると、これに関するMicrosoftのいくつかの未解決の問題が見つかります。うまくいけば、将来的にこの問題が修正されるでしょう。

お役に立てれば。

更新：

ビルドエージェントで機能するこの問題の恒久的な修正を見つけると、新しいNuGet PackageReferenceモデルに移行した場合（で.csprojはないpackages.config）の方がうまく機能する傾向があることに気づきました。このアップグレードの方法に関するガイドへのリンクは次のとおりです。https：//docs.microsoft.com/en-us/nuget/reference/migrate-packages-config-to-package-reference

私のためにバインディングリダイレクトを削除するとうまくいきました、あなたはそれを削除してみることができます：

<bindingRedirect oldVersion="0.0.0.0-4.2.0.0" newVersion="4.2.0.0" />

@AndreiUによる回答と、ローカルで実行時エラーを再現する方法への追加。

ローカルではなくAzureにデプロイすると、以下のランタイムエラーが発生しました。

ファイルまたはアセンブリ 'System.Net.Http、Version = 4.2.0.0、Culture = neutral、PublicKeyToken = b03f5f7f11d50a3a'またはその依存関係の1つを読み込めませんでした。指定されたファイルが見つかりません。 "、" ExceptionType "：" System.IO.FileNotFoundException "、" StackTrace "：" at Company.Project.Service.CompanyIntegrationApiService..ctor（Uri baseAddress）\ r \ n Company.Project .BackOffice.Web.Controllers.OrderController..ctor（）in C：\ projects \ company-project \ src \ Company.Project.BackOffice.Web \ Controllers \ Order \ OrderController.cs：line 30 \ r \ n at lambda_method（クロージャ）\ r \ n System.Web.Http.Dispatcher.DefaultHttpControllerActivator.Create（HttpRequestMessage request、HttpControllerDescriptor controllerDescriptor、Type controllerType） "}}で Culture = neutral、PublicKeyToken = b03f5f7f11d50a3a 'またはその依存関係の1つ。指定されたファイルが見つかりません。 "、" ExceptionType "：" System.IO.FileNotFoundException "、" StackTrace "：" at Company.Project.Service.CompanyIntegrationApiService..ctor（Uri baseAddress）\ r \ n at Company.Project .BackOffice.Web.Controllers.OrderController..ctor（）in C：\ projects \ company-project \ src \ Company.Project.BackOffice.Web \ Controllers \ Order \ OrderController.cs：line 30 \ r \ n at lambda_method（クロージャ）\ r \ n System.Web.Http.Dispatcher.DefaultHttpControllerActivator.Create（HttpRequestMessage request、HttpControllerDescriptor controllerDescriptor、Type controllerType） "}}で Culture = neutral、PublicKeyToken = b03f5f7f11d50a3a 'またはその依存関係の1つ。指定されたファイルが見つかりません。 "、" ExceptionType "：" System.IO.FileNotFoundException "、" StackTrace "：" at Company.Project.Service.CompanyIntegrationApiService..ctor（Uri baseAddress）\ r \ n at Company.Project .BackOffice.Web.Controllers.OrderController..ctor（）in C：\ projects \ company-project \ src \ Company.Project.BackOffice.Web \ Controllers \ Order \ OrderController.cs：line 30 \ r \ n at lambda_method（クロージャ）\ r \ n System.Web.Http.Dispatcher.DefaultHttpControllerActivator.Create（HttpRequestMessage request、HttpControllerDescriptor controllerDescriptor、Type controllerType） "}}で

アセンブリを検討し始めたとき、私のWebプロジェクトとサービスプロジェクトがの異なるバージョンをターゲットにしていることがわかりましたSystem.Net.Http。

Webプロジェクト：

奉仕プロジェクト：

これはバージョンの不一致が原因であると考えるのは簡単ですが、ここで重要なのはエラーを確認することThe system cannot find the file specified.です。

パスプロパティを見ると、Webプロジェクトが.Net Frameworkアセンブリをターゲットにしているのに対し、サービスはVisual Studio 2017のアセンブリをターゲットにしていることがわかります。サーバーにVisual Studio 2017がインストールされていないため、ランタイムエラーが発生します。

Webパス：

C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.6.1\System.Net.Http.dll

サービスパス：

C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\lib\System.Net.Http.dll

設定Copy Localするtrueだけの簡単な方法で問題を解決できますが、すべての場合ではありません。

ローカルマシンでエラーを再現するにSystem.Net.Http.dllは、Visual Studio固有のフォルダーから必要なものを削除するだけです。これにより、ランタイムエラーが発生し、おそらくいくつかのビルドエラーが発生します。これらが修正された後、すべてが機能するはずですが、少なくとも私にとってはうまくいきました。

バージョンを見て、どのアセンブリが使用されているかSystem.Net.HttpをNuGet確認してインストールした場合.csproj。System.Net.Http 4.3.4たとえば、次のアセンブリを提供します。

<Reference Include="System.Net.Http, Version=4.1.1.3, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL">
  <HintPath>..\packages\System.Net.Http.4.3.4\lib\net46\System.Net.Http.dll</HintPath>
  <Private>True</Private>
  <Private>True</Private>
</Reference>

Jenkins、TeamCity、AppVeyorなどのビルドサーバーを使用している場合は、ランタイムが不足している.dll可能性もあります。この場合、NuGetバージョンのSystem.Net.Httpを使用したり、不足しているものを.dllローカルで削除したりしても役に立たない場合があります。このエラーを解決するには、見つからないバージョンと特定のバージョンを確認しますPublicKeyToken。その後、いずれWeb.configかで、またはApp.configプロジェクトに応じて、バインディングリダイレクトを作成します。私の場合、代わりに4.0.0.0を使用したいと思います。

<dependentAssembly>
  <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
  <bindingRedirect oldVersion="0.0.0.0-4.2.0.0" newVersion="4.0.0.0" />
</dependentAssembly>

この問題についての良いGithubスレッド：

https://github.com/dotnet/corefx/issues/22781

問題を修正するために私がしたことは、web.configからすべてのバインディングを削除し、

Update-Package -reinstall

これにより、おそらくそこにある必要がない古いバインディングの束が削除され、実際に適切なクリーニングが行われました。

System.Net.HttpNuGetを使用してインストールしました。ここでそれをつかむことができます：

https://www.nuget.org/packages/System.Net.Http/

ASP.NET MVCこのプロジェクトは、私が目標に取り組んでいます.NET 4.6.1。IIS ExpressVisual Studio 2019でデバッグしているときに、私のマシンで完全に動作します。

この問題は、Azureにデプロイされたアプリケーションを実行しようとしたときに発生しました。私はこのエラーを受け取りました：

ファイルまたはアセンブリ 'System.Net.Http、Version = 4.2.0.0、Culture = neutral、PublicKeyToken = b03f5f7f11d50a3a'またはその依存関係の1つを読み込めませんでした。

私の場合に実際に機能したのは、.csprojファイルを開いてSystem.Net.Http、次のスクリーンショットのように検索したことです...

.csprojファイルにバージョンがあることを確認します4.1.1.3。

<Reference Include="System.Net.Http, Version=4.1.1.3, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL">

は<HintPath>実際には..\packagesNuget のフォルダを指しています。つまり、これはNugetによってインストールされた実際のバージョンです。デプロイすると、この特定のバージョンもサーバー側で復元され、すべてがバインドリダイレクトで機能するはずです。

...したがって、バインディングリダイレクトでは、この特定のバージョンを次のWeb.configように記述する必要があります。

<dependentAssembly>
    <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-4.2.0.0" newVersion="4.1.1.3" />
</dependentAssembly>

これにより、Azure Kuduに 2、3回コミットした後の私の問題が修正されました。Azure Webサイトがエラーなしで開始しました。

このエラーは、サーバーの1つにWebサービスをデプロイしたときに発生しました。プロジェクトは、サーバーにインストールされていない.Netフレームワーク4.7.2をターゲットにしました。サーバーに4.7.2フレームワークをインストールすると、問題が修正されました。

Andrei Uの答えは私の救いにつながります。しかし、推論は私のケースと一致しませんでした。私と同じシナリオにいる人のために：

これはランタイムエラー（ビルド時間ではなく）であり、ビルドは成功しましたが、1台のコンピューターでは機能しましたが、サーバーでは機能しませんでした。解決策：-System.Net.Httpパッケージを追加しました。-ファイル名を変更：C：\ Program Files（x86）\ Reference Assemblies \ Microsoft \ Framework.NETFramework \ v4.7.2 \ System.Net.Http.dll（eg rename to：System.Net.Http.dll.BAK）on theサーバーを構築します。

このdllのアセンブリリダイレクトがありませんでしたが、まだありません

簡単な解決策の1つとして、Webプロジェクトのターゲットフレームワークを4.6にダウングレードしました。

私はクライアントとWebアプリケーションを作成します。クライアントは.netフレームワーク4.7.1を持ち、Webは同じで、同じ問題に直面しています。Webのターゲット.netフレームワークをダウングレードするとうまくいきます。

数日間これに苦労した後、ようやくプロジェクトの.Net 4.7.2 / System.Net.Httpの問題を修正しました。* .csprojファイルを変更してフレームワークバージョン4.7.2をターゲットにすることに加えて、次のプロジェクトのapp.configも更新する必要がありました。

<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.6.1" />

に：

<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.7.2" />

私も同じ問題を抱えていました。最後に、Deploy-FabricApplication.ps1を次のように変更して解決しました

$binFolder = "$LocalFolder\..\..\..\..\Bin"

$httpDllLocation = "$binFolder\System.Net.Http.dll"
$codeFolder = "$ApplicationPackagePath\[ProjectName].ServicesPkg\Code"
$configFile = "$codeFolder\[ProjectName].Services.exe.config"

Copy-Item $httpDllLocation -Destination $codeFolder 

$appConfig = [xml](cat $configFile)
$appConfig.configuration.runtime.assemblyBinding.dependentAssembly | foreach {

    $name = $_.assemblyIdentity.name
    #Write $name
    if($name -eq 'System.Net.Http')
    {
        Write 'System.Net.Http changed'

        $_.bindingRedirect.newVersion = '4.2.0.0'
    }
}
$appConfig.Save($configFile)

x64の4.2.0.0 System.Net.Http.dllを見つけました。このスクリプトをデプロイする前に、dllをパッケージディレクトリにコピーし、このファイルを明示的に使用するように構成ファイルを変更します。System.Net.Httpの問題に関するブログもhttp://gertjanvanmontfoort.blogspot.nl/2017/11/systemnethttp-dll-version-problems.htmlで書きました。

[ProjectName]を自分のプロジェクト名に置き換えることを忘れないでください

これがお役に立てば幸いです。

私にとっては本当に奇妙なことでした。問題が何であるかを見つけた後、何時間ものデバッグが必要でした。ローカルでは発生しませんでしたが、jenkinsを使用してプロジェクトをビルドした場合にのみ発生しました。

私はdotnet standart 2.0を使用する小さなライブラリを持っていて、メインプロジェクトは通常の.NETに基づいたWCFプロジェクトでした（私のものは特にv4.6.1でした）。しかし、dotnet標準ライブラリのスタートアップクラスには、次のようなコードが含まれていました。

public static class CoreModule
{
    public static IServiceCollection AddStaticDataConfiguration(
        this IServiceCollection services, Func<IServiceProvider, IStaticDataConfiguration>  staticDataConfiguration) 
    {  
        services.TryAddSingleton(staticDataConfiguration);
        services.TryAddSingleton<Func<HttpClient>>(x =>
        {
            var configuration = staticDataConfiguration(x);

            return configuration.ClientResolver ?? (() => new HttpClient());
        });
        return services;
    }
}

IStaticDataConfigurationインターフェイスは次のようになります。

public interface IStaticDataConfiguration
{
    //..... some stuff

    Func<HttpClient> ClientResolver { get; set; }
}  

このインターフェイスはdotnet標準ライブラリの内部にありますが、実装は外部（WCFプロジェクトにあります）です。

ライブラリの外側から、AddStaticDataConfiguration以下のようなメソッドを呼び出していました。

serviceCollection.AddStaticDataConfiguration(p =>
{
    var staticDataConfig = p.GetService<IStaticDataConfiguration>();
    return new StaticDataProviderConfiguration
    {
        //...some other stuff
        ClientResolver = () => restRequestFactory.GetInstrumentedClient("StaticDataService") //this returns an HttpClient
    };
});

問題はFunc<HttpClient>、通常の.NETプロジェクトからdotnetスタンダートライブラリにを渡そうとしていることです。これは、なんらかの理由でdotnetスタンダートが好きではなく、おそらくHttpClient別のクラスからのものであると考えSystem.Net.Http 4.x.x.xられるため、見つからない例外がスローされます。HttpClient通常の.NETプロジェクトからを受け入れないようにコードを削除したがfunc、ライブラリ自体の中に新しいものを作成した場合、それは満足して正常に機能します。このエラーは非常に多くの理由で発生しているので、これが他の誰かの助けになることを願っています:)

私の解決策は@Raquibのものに似ていました。私のプロジェクトは4.7.2で、私のPCでは問題なく動作しました。開発サーバーにデプロイしたときはいつでも、質問で述べた問題が発生します。サーバーで最も高い.netバージョンは4.6.1であることがわかりました。プロジェクトを4.6.1にダウングレードすると問題が解決しました。サーバーの.netバージョンをアップグレードすることは私の選択肢ではありませんでした。

答えの一部はMicrosoftのドキュメントに記載されていると思います。

.NET Framework 4.5.1以降のバージョンを対象とするVisual Studioでデスクトップアプリを作成すると、アプリは自動バインディングリダイレクトを使用します。

@Vivek Sharmaの回答が指摘するように、以下を削除します。

<bindingRedirect oldVersion="0.0.0.0-4.2.0.0" newVersion="4.2.0.0" />

私のアプリでそのような3つのケースで問題を解決しました。たとえば、PowershellでDLLを調べると、次のようになります。

 ([system.reflection.assembly]::loadfile("C:\MyApp\bin\System.Net.Sockets.dll")).FullName

アウトプット

System.Net.Sockets、バージョン= 4.0.0.0

ビンに4.2.0.0出力4.0.0.0しているので、バインディングリダイレクトが機能しないことは明らかです。

また、GACをチェックして、そこにもアセンブリがないかどうかを確認する価値があります。

 gacutil -l System.Net.Sockets

私の場合、特定のバージョンもGACにありませんでした。DLLがGACにあった場合、それはアセンブリバインディングプロセスで検出されているはずです。

まず、ローカルファイルシステムから削除します。

C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\lib\Syste.Net.Http.dll

次に、プロジェクト内のすべての参照を削除し、4.0参照を追加します。
これで私の問題は解決しました。