13

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

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

有关此设置的 MSDN 文档实际上不存在,而且我发现确实说异步编程需要它的帖子似乎是在 WebForms 的上下文中。

所以这是我的问题:

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

以下是我看过的一些文章UseTaskFriendlySynchronizationContext

一些真正帮助我了解所有这些东西是如何工作的文章从未提及UseTaskFriendlySynchronizationContext

4

1 回答 1

15

缺少的关键参考是这篇博文。具体来说,您需要设置设置UseTaskFriendlySynchronizationContext targetFramework. 4.5创建一个新项目设置targetFramework4.5,因此您确实获得了正确的行为(UseTaskFriendlySynchronizationContext隐式设置为true)。

要回答您的具体问题:

  1. 该设置会影响对各种请求的 ASP.NET 请求处理,而不仅仅是 WebForms。
  2. 大多数async教程都假设一个 GUI 应用场景。
  3. 我不知道; 我认为这作为一个单独的问题会更好。我的直觉是,离开 ASP.NET 上下文后,您将无法依赖。Thread.CurrentPrincipal
于 2013-12-09T19:43:29.563 回答