ASP.Net vs MVC vs WebAPI和UseTaskFriendlySynchronizationContext

Mad*_*ter 13 asp.net asp.net-mvc synchronizationcontext async-await asp.net-web-api

我有几个ASP.Net MVC和WebAPI项目.其中大多数都是最新的(MVC 5/WebAPI 2).我一直在仔细检查我的安全假设,因为我正在实现一个全局过滤器(用于MVC)和一个委托处理程序(用于WebAPI)来统一整个系统的安全性.

在这种情况下,我遇到了一些文章和帖子(见下文),其中说你应该总是设置UseTaskFriendlySynchronizationContexttrue(默认为false).这对我来说似乎很奇怪,因为即使在VS2013中使用MVC 5和WebAPI 2新项目模板(以及ASP.Net WebForms模板)也根本不设置此应用程序设置.

关于此设置的MSDN文档几乎不存在,我发现的帖子确实说它是异步编程所必需的,似乎是在WebForms的上下文中.

所以这是我的问题:

  1. 此设置是否适用于ASP.Net的所有内容,还是特定于ASP.Net中的页面生命周期内容(我没有多少使用)
  2. 如果它对于现代异步编程至关重要,为什么没有任何教程或模板引用它?
  3. 在使用ConfigureAwait(false)的引用库中使用Thread.CurrentPrincipal的声明会造成任何问题,或者ExecutionContext的逻辑调用上下文的流动会在那里照顾我吗?(到目前为止我的阅读和测试表明它会)

以下是我见过的一些文章UseTaskFriendlySynchronizationContext:

一些文章真正帮助我掌握了所有这些东西的作用,从未提及UseTaskFriendlySynchronizationContext:

Ste*_*ary 15

缺少的关键参考是这篇博文.具体来说,您需要任何设置UseTaskFriendlySynchronizationContext 设置targetFramework4.5.创建一个新项目设置targetFramework4.5,所以你确实得到了正确的行为(UseTaskFriendlySynchronizationContext隐式设置为true).

回答您的具体问题:

  1. 该设置会影响对各种请求的ASP.NET请求处理,而不仅仅是WebForms.
  2. 大多数async教程都假设一个GUI应用程序场景.
  3. 我不确定; 我认为这会作为一个单独的问题更好.我的直觉是,在离开ASP.NET上下文后,你不能依赖它Thread.CurrentPrincipal.