J'ai le code WebAPI de test suivant, je n'utilise pas WebAPI en production mais je l'ai fait à cause d'une discussion que j'ai eue sur cette question : Question sur l'interface WebAPI asynchrone
Quoi qu'il en soit, voici la méthode WebAPI incriminée :
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";
}J'avais cru jusqu'ici que la deuxième exception était attendue parce que, lorsque les await complète, ce sera probablement sur un autre fil de discussion où HttpContext.Current en tant que variable statique ne sera plus résolu à la valeur appropriée. Maintenant, sur la base du contexte de synchronisation, il pourrait être forcé de revenir au même thread après l'attente, mais je ne fais rien de compliqué dans mon test. C'est juste une simple utilisation naïve de await .
Dans les commentaires d'une autre question, on m'a dit que HttpContext.Current doit être résolu après une attente. Il y a même un autre commentaire sur cette question qui indique la même chose. Alors, qu'est-ce qui est vrai ? Doit-il être résolu ? Je pense que non, mais je veux une réponse faisant autorité sur ce point car async y await est assez récente pour que je ne puisse pas trouver quelque chose de définitif.
TL;DR : Est HttpContext.Current potentiellement null après un await ?
