待機後にHttpContext.Currentがnullになるのはなぜですか？

Question 1

私は次のテストWebAPIコードを持っています。本番環境ではWebAPIを使用していませんが、この質問について話し合ったために作成しました。WebAPI非同期の質問

とにかく、これが問題のあるWebAPIメソッドです。

public async Task<string> Get(int id)
{
    var x = HttpContext.Current;
    if (x == null)
    {
        // not thrown
        throw new ArgumentException("HttpContext.Current is null");
    }

    await Task.Run(() => { Task.Delay(500); id = 3; });

    x = HttpContext.Current;
    if (x == null)
    {
        // thrown
        throw new ArgumentException("HttpContext.Current is null");
    }

    return "value";
}

私はこれまで、2番目の例外が予想されると信じていawaitました。これは、完了すると、別のスレッドで発生する可能性が高くHttpContext.Current、thread-static変数が適切な値に解決されなくなるためです。さて、同期コンテキストに基づいて、待機後に実際には同じスレッドに戻ることを強制される可能性がありますが、テストでは特別なことは何もしていません。これは、の単純で素朴な使用法ですawait。

別の質問のコメントでHttpContext.Current、待ってから解決する必要があると言われました。同じことを示すこの質問にはさらに別のコメントがあります。では、何が本当ですか？それは解決する必要がありますか？いいえと思いますが、これについては信頼できる答えが必要です。なぜならasync、それawaitは十分に新しいので、決定的なものを見つけることができないからです。

TL; DR：HttpContext.Current潜在的nullにawait？

Question 2

ASP.NET 4.5アプリケーションを作成し、4.5をターゲットにしていることを確認してください。asyncそしてawaitあなたは4.5上で実行されていない限りASP.NETでの未定義の動作を持っているし、新しい「タスクに優しい」同期コンテキストを使用しています。

特に、これは次のいずれかを行う必要があることを意味します。

設定するhttpRuntime.targetFrameworkには4.5、または
でappSettings、に設定aspnet:UseTaskFriendlySynchronizationContextしtrueます。

詳細については、こちらをご覧ください。

Question 3

@StephenClearyが正しく指摘しているように、web.configでこれが必要です。

<httpRuntime targetFramework="4.5" />

これを最初にトラブルシューティングしたとき、上記をソリューション全体で検索し、すべてのWebプロジェクトに存在することを確認し、すぐに原因として却下しました。最終的に、これらの検索結果を完全なコンテキストで見ることになりました。

<!--
  For a description of web.config changes for .NET 4.5 see http://go.microsoft.com/fwlink/?LinkId=235367.

  The following attributes can be set on the <httpRuntime> tag.
    <system.Web>
      <httpRuntime targetFramework="4.5" />
    </system.Web>
-->

ドー。

レッスン：Webプロジェクトを4.5にアップグレードする場合でも、その設定を手動で行う必要があります。

Question 4

私のテストに欠陥がありますか、それともここで欠落しているweb.config要素があり、待機後にHttpContext.Currentが正しく解決されますか？

テストに欠陥はなく、待機後にHttpContext.Currentがnullになることはありません。これは、ASP.NET Web APIで待機すると、この待機に続くコードに、待機前に存在していた正しいHttpContextが確実に渡されるためです。

Question 5

私は最近この問題に遭遇しました。Stephenが指摘したように、ターゲットフレームワークを明示的に設定しないと、この問題が発生する可能性があります。

私の場合、Web APIはバージョン4.6.2に移行されましたが、ランタイムターゲットフレームワークがWeb構成で指定されなかったため、基本的にこれは<system.web>タグ内にありませんでした。

実行しているフレームワークのバージョンに疑問がある場合は、これが役立つ場合があります。WebAPIメソッドのいずれかに次の行を追加し、ブレークポイントを設定して、実行時に現在ロードされているタイプを確認し、レガシー実装ではないことを確認します。

これが表示されるはずです（AspNetSynchronizationContext）：

LegazyAspNetSynchronizationContextの代わりに（ターゲットフレームワークを追加する前に見たもの）：

ソースコード（https://referencesource.microsoft.com/#system.web/LegacyAspNetSynchronizationContext.cs）にアクセスすると、このインターフェイスのレガシー実装には非同期サポートがないことがわかります。

私は問題の原因を見つけるために多くの時間を費やし、スティーブンの対応は大いに役立ちました。この回答が問題に関する詳細情報を提供することを願っています。