在WebApi或MVC控制器中使用ConfigureAwait（false）是否存在任何危险？

Question

假设我有两种情况：

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

我一直在阅读什么时候应该使用配置等待，似乎我应该在所有未直接绑定到UI的异步调用上使用配置等待（false）。不过，我不知道这意味着什么...我应该使用吗？在所有上述wait调用上配置等待（false）？

我正在寻找一些明确的指导方针，关于我应该何时使用它。

这个问题不同于为所有服务器端代码调用ConfigureAwait的最佳实践——我在寻找一个关于这个方法在WebApi和MVC环境中的用例的直接答案，而不是一般的C#。

Answer 1

你可以使用配置等待公共行动MVC控制器，它有助于防止交易锁，如果你的_userService.GetAuthViewModelAsync继续等待。

请看下面的链接来了解这个案例:

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

Answer 2

如果 ASP.NET Core 应用程序中没有实际的上下文，则添加 应该不会造成任何伤害或好处。ConfigureAwait（false） 到您的可等待方法到控制器中。

但是，如果将来有可能最终出于某种原因，需要考虑一些背景，就像 ASP.NET 4一样，那将是一个不同的故事。我们不能冒险在不同的上下文中运行，除非我们不对此表示不满（在这种情况下，我们可以使用任何可用于处理的线程，从而可能提高性能）。

我在这里的选择是添加 ConfigureAwait（false），即使它没有被使用。

Answer 3

似乎我应该在所有不直接绑定到UI的异步调用上使用ConfigalAwait（false）。

不完全是。这条准则在这里没有意义，因为没有UI线程。

传递给< code > configurewait 的参数是< code > continueOnCapturedContext ，它更清楚地解释了这种情况。只要< code>async方法的其余部分不依赖于当前上下文，就要使用< code > configurewait(false)。

在ASP.NET4. x中，“上下文”是请求上下文，它包括HttpContext.Current和区域性等内容。此外——这是未记录的部分——许多ASP.NET助手方法确实依赖于请求上下文。

(附注:ASP.NET核心不再有“背景”)

我应该使用。所有上述Await调用的configurewait(false )?

我还没有听到任何关于此的坚定指导，但我怀疑这没关系。

在我自己的代码中，我从未在控制器操作方法中使用< code > configurewait(false)，因此它们已经在请求上下文中完成。我觉得这样更好。