Perché HttpContext.Current è null dopo await?

Ho il seguente codice WebAPI di prova, non utilizzo WebAPI in produzione ma l'ho fatto a causa di una discussione che ho avuto su questa domanda: WebAPI Async question

Ad ogni modo, ecco il metodo WebAPI incriminato:

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";
}

Finora avevo creduto che la seconda eccezione fosse prevista perché quando il awaitcompletamento sarà probabilmente su un thread diverso dove HttpContext.Currentcome variabile thread-static non si risolverà più al valore appropriato. Ora, in base al contesto di sincronizzazione, potrebbe effettivamente essere costretto a tornare allo stesso thread dopo l'attesa, ma non sto facendo nulla di stravagante nel mio test. Questo è solo un uso semplice e ingenuo di await.

Nei commenti in un'altra domanda mi è stato detto che HttpContext.Currentdovrebbe risolversi dopo un'attesa. C'è anche un altro commento su questa domanda che indica lo stesso. Allora cosa è vero? Dovrebbe risolversi? Penso di no, ma voglio una risposta autorevole su questo perché asynced awaitè abbastanza nuovo da non riuscire a trovare nulla di definitivo.

TL; DR: è HttpContext.Currentpotenzialmente nulldopo un await?

Assicurati di scrivere un'applicazione ASP.NET 4.5 e di avere come target 4.5. asynce awaithanno un comportamento indefinito su ASP.NET a meno che non si stia eseguendo su 4.5 e si utilizzi il nuovo contesto di sincronizzazione "facile da usare".

In particolare, questo significa che devi:

• Impostare httpRuntime.targetFrameworksu 4.5, o
• Nel tuo appSettings, impostato aspnet:UseTaskFriendlySynchronizationContextsu true.

Maggiori informazioni sono disponibili qui .

Come ha sottolineato correttamente @StephenCleary, ne hai bisogno nel tuo web.config:

<httpRuntime targetFramework="4.5" />

Quando stavo risolvendo questo problema per la prima volta, ho effettuato una ricerca a livello di soluzione per quanto sopra, ho confermato che era presente in tutti i miei progetti web e l'ho rapidamente liquidato come colpevole. Alla fine mi è venuto in mente di guardare quei risultati di ricerca nel contesto completo:

<!--
  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>
-->

Doh.

Lezione: se si aggiorna un progetto Web a 4.5, è comunque necessario impostare manualmente tale impostazione.

Il mio test è difettoso o c'è qualche elemento web.config che mi manca qui che farebbe risolvere correttamente HttpContext.Current dopo un'attesa?

Il tuo test non è difettoso e HttpContext.Current non dovrebbe essere nullo dopo l'attesa perché nell'API Web ASP.NET quando attendi, questo assicurerà che il codice che segue questo attese venga passato l'HttpContext corretto che era presente prima dell'attesa.

Mi sono imbattuto in questo problema di recente. Come ha sottolineato Stephen, non impostare esplicitamente il framework di destinazione può generare questo problema.

Nel mio caso, la nostra API Web è stata migrata alla versione 4.6.2 ma il framework di destinazione del runtime non è mai stato specificato nella configurazione web, quindi sostanzialmente questo mancava all'interno del tag <system.web>:

In caso di dubbi sulla versione del framework in esecuzione, ciò può essere d'aiuto: aggiungere la seguente riga su uno dei metodi dell'API Web e impostare un punto di interruzione per verificare quale tipo è attualmente caricato in fase di esecuzione e verificare che non sia un'implementazione Legacy:

Dovresti vedere questo (AspNetSynchronizationContext):

Invece di LegazyAspNetSynchronizationContext (che era quello che ho visto prima di aggiungere il framework di destinazione):

Se vai al codice sorgente ( https://referencesource.microsoft.com/#system.web/LegacyAspNetSynchronizationContext.cs ) vedrai che l'implementazione Legacy di questa interfaccia manca di supporto asincrono.

Ho passato molto tempo a cercare di trovare la fonte del problema e la risposta di Stephen è stata di grande aiuto. Spero che questa risposta fornisca ulteriori informazioni sul problema.