c# - net - web api async

¿Existe algún peligro al utilizar ConfigureAwait(falso) en los controladores WebApi o MVC?

Question

Digamos que tengo dos escenarios:

1) Controlador 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) Controlador 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);
        }
    }

He estado leyendo sobre cuándo debería usar ConfigureAwait y parece que debería usar ConfigureAwait(false) en TODAS mis llamadas asíncronas que no están vinculadas directamente a la IU. Sin embargo, no sé qué significa eso ... ¿debería estar utilizando .ConfigureAwait(false) en todas las llamadas en await anteriores?

Estoy buscando algunas pautas inequívocas sobre cuándo exactamente debería usarlo.

Esta pregunta NO es la misma que la Práctica recomendada para llamar a ConfigureAwait para todos los códigos del lado del servidor . Estoy buscando una respuesta directa en el caso de uso de este método en el contexto de WebApi y MVC, no como C # general.

Answer 1

Parece que debería usar ConfigureAwait (falso) en TODAS mis llamadas asíncronas que no están vinculadas directamente a la interfaz de usuario.

No exactamente. Esa guía no tiene sentido aquí, ya que no hay un hilo de interfaz de usuario.

El parámetro pasado a ConfigureAwait es continueOnCapturedContext , que explica más claramente el escenario. Desea utilizar ConfigureAwait(false) siempre que el resto de ese método async no dependa del contexto actual.

En ASP.NET 4.x, el "contexto" es el contexto de solicitud, que incluye elementos como HttpContext.Current y culture. Además, y esta es la parte no documentada, muchos de los métodos de ayuda de ASP.NET dependen del contexto de la solicitud.

(Nota al margen: ASP.NET Core ya no tiene un "contexto")

¿Debo usar .ConfigureAwait (falso) en todas las llamadas en espera anteriores?

No he escuchado ninguna guía firme sobre esto, pero sospecho que está bien.

En mi propio código, nunca uso ConfigureAwait(false) en los métodos de acción de mi controlador, para que se completen ya dentro del contexto de la solicitud. Simplemente me parece más correcto.

Answer 2

El uso de ConfigureAwait(false) en los controladores no me suena bien, ya que hará que el hilo principal espere hasta que finalice la operación. Lo mejor que he descubierto es usarlo en la capa Servicio / Empresa y en la capa Persistencia.

Answer 3

Puede usar ConfigureAwait en el controlador de MVC de acción pública, esto ayuda a evitar el bloqueo de transacciones si su _userService.GetAuthViewModelAsync sigue esperando. La nube genera interbloqueos si el servicio asíncrono sigue esperando, por lo que puede bloquear httpcontext de la interfaz de usuario.

Mira el siguiente enlace para entender este caso:

http://blog.stephencleary.com/2012/07/dont-block-on-async-code.html