在WebApi或MVC控制器中使用ConfigureAwait（false）有任何危险吗？

Say I have two scenarios:

说我有两个场景：

1) WebApi Controller

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 Controller

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

I've been reading up on when I should use ConfigureAwait and it seems like I should use ConfigureAwait(false) on ALL of my async calls that are not tied directly to the UI. I don't know what that means though... should I be using .ConfigureAwait(false) on all of the above await calls?

我一直在阅读何时应该使用ConfigureAwait，似乎我应该在所有不直接绑定到UI的异步调用上使用ConfigureAwait（false）。我不知道这意味着什么......我应该在所有上述await调用中使用.ConfigureAwait（false）吗？

I'm looking for some unambiguous guidelines around when exactly I should be using it.

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

This question is NOT the same as the Best practice to call ConfigureAwait for all server-side code - I am looking for a straightforward answer on the use-case for this method in the context of WebApi and MVC, not as general C#.

这个问题与为所有服务器端代码调用ConfigureAwait的最佳实践不同 - 我正在寻找关于WebApi和MVC上下文中此方法的用例的简单答案，而不是一般的C＃。

2 个解决方案

#1

it seems like I should use ConfigureAwait(false) on ALL of my async calls that are not tied directly to the UI.

看起来我应该在所有不直接绑定到UI的异步调用上使用ConfigureAwait（false）。

Not quite. That guideline doesn't make sense here, since there is no UI thread.

不完全的。这条指南在这里没有意义，因为没有UI线程。

The parameter passed to ConfigureAwait is continueOnCapturedContext, which explains more clearly the scenario. You want to use ConfigureAwait(false) whenever the rest of that async method does not depend on the current context.

传递给ConfigureAwait的参数是continueOnCapturedContext，它更清楚地解释了该场景。只要该异步方法的其余部分不依赖于当前上下文，您就希望使用ConfigureAwait（false）。

In ASP.NET 4.x, the "context" is the request context, which includes things like HttpContext.Current and culture. Also - and this is the undocumented part - a lot of the ASP.NET helper methods do depend on the request context.

在ASP.NET 4.x中，“context”是请求上下文，其中包括HttpContext.Current和culture等内容。另外 - 这是未记录的部分 - 许多ASP.NET辅助方法确实依赖于请求上下文。

(Side note: ASP.NET Core no longer has a "context")

（旁注：ASP.NET Core不再具有“上下文”）

should I be using .ConfigureAwait(false) on all of the above await calls?

我应该在所有上述await调用中使用.ConfigureAwait（false）吗？

I haven't heard any firm guidance on this, but I suspect it's OK.

我没有听到任何关于此的确切指导，但我怀疑它没关系。

In my own code, I never use ConfigureAwait(false) in my controller action methods, so that they complete already within the request context. It just seems more right to me.

在我自己的代码中，我从不在我的控制器操作方法中使用ConfigureAwait（false），因此它们已经在请求上下文中完成。这对我来说似乎更合适。

#2

-1

You may use ConfigureAwait on public action MVC Controller, it help to prevent deal lock if your _userService.GetAuthViewModelAsync keeps waiting. it cloud raise deadlock if async service keeps await so by may block httpcontext of UI.

您可以在公共操作MVC Controller上使用ConfigureAwait，如果_userService.GetAuthViewModelAsync保持等待，它有助于防止交易锁定。如果异步服务保持等待，它会阻止UI的httpcontext。

Have look below link to understand this case:

看看下面的链接了解这种情况：

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

#1