Y a-t-il un danger à utiliser ConfigureAwait (false) dans les contrôleurs WebApi ou MVC?

Question

Disons que j'ai deux scénarios:

1) Contrôleur WebApi

    [System.Web.Http.HttpPost]
    [System.Web.Http.AllowAnonymous]
    [Route("api/registerMobile")]
    public async Task<HttpResponseMessage> RegisterMobile(RegisterModel model)
    {
        var registerResponse = await AuthUtilities.RegisterUserAsync(model, _userService, User);
        if (registerResponse.Success) {
            var response = await _userService.GetAuthViewModelAsync(model.Username, User);
            return Request.CreateResponse(HttpStatusCode.OK, new ApiResponseDto() { Success = true, Data = response });
        }
        else {
            return Request.CreateResponse(HttpStatusCode.OK, registerResponse);
        }

    }

2) Contrôleur MVC

    [Route("public")]
    public async Task<ActionResult> Public()
    {
        if (User.Identity.IsAuthenticated)
        {
            var model = await _userService.GetAuthViewModelAsync(User.Identity.Name);
            return View("~/Views/Home/Index.cshtml", model);
        }
        else
        {
            var model = await _userService.GetAuthViewModelAsync(null);
            return View("~/Views/Home/Index.cshtml", model);
        }
    }

J'ai lu quand je devrais utiliser ConfigureAwait et il semble que je devrais utiliser ConfigureAwait(false) sur TOUS mes appels asynchrones qui ne sont pas directement liés à l'interface utilisateur. Je ne sais pas ce que cela signifie cependant ... devrais-je utiliser .ConfigureAwait(false) sur tous les appels await ci-dessus?

Je cherche des directives sans ambiguïté sur le moment exact où je devrais l'utiliser.

Cette question n'est PAS la même que la Meilleure pratique pour appeler ConfigureAwait pour tout le code côté serveur - Je cherche une réponse simple sur le cas d'utilisation de cette méthode dans le contexte de WebApi et MVC, pas aussi général que C #.

Answer 1

il semble que je devrais utiliser ConfigureAwait (false) sur TOUS mes appels asynchrones qui ne sont pas directement liés à l'interface utilisateur.

Pas assez. Cette directive n'a pas de sens ici, car il n'y a pas de thread d'interface utilisateur.

Le paramètre passé à ConfigureAwait est continueOnCapturedContext, ce qui explique plus clairement le scénario. Vous voulez utiliser ConfigureAwait(false) chaque fois que le reste de cette méthode asyncpas dépend du contexte actuel.

Dans ASP.NET 4.x, le "contexte" est le contexte de la demande, qui inclut des éléments comme HttpContext.Current Et la culture. De plus - et c'est la partie non documentée - beaucoup de méthodes d'assistance ASP.NET do dépendent du contexte de la demande.

(Note latérale: ASP.NET Core n'a plus de "contexte")

dois-je utiliser .ConfigureAwait (false) sur tous les appels en attente ci-dessus?

Je n'ai entendu aucune indication ferme à ce sujet, mais je pense que c'est OK.

Dans mon propre code, je n'utilise jamais ConfigureAwait(false) dans mes méthodes d'action de contrôleur, afin qu'elles se terminent déjà dans le contexte de la demande. Cela me semble plus juste.