ASP.Net vs MVC vs WebAPI 和 UseTaskFriendlySynchronizationContext

Question

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

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

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

所以这是我的问题：

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

这是我看到的一些关于UseTaskFriendlySynchronizationContext的文章：

• Set Thread.CurrentPrincipal Asynchronously?
• ASP.NET appSettings Element on MSDN
• What's the meaning of "UseTaskFriendlySynchronizationContext"?
• Understanding the SynchronizationContext in ASP.NET by Marcus van Houdt
• Why is an "await Task.Yield()" required for Thread.CurrentPrincipal to flow correctly?

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

• ExecutionContext vs SynchronizationContext by Stephen Toub
• It's All About the SynchronizationContext by Stephen Cleary

Answer 1

缺少的键引用是this blog post。具体来说，您需要要么 设置UseTaskFriendlySynchronizationContext 或 将targetFramework 设置为4.5。创建一个新项目会将targetFramework 设置为4.5，因此您确实得到了正确的行为（UseTaskFriendlySynchronizationContext 被隐式设置为true）。

回答您的具体问题：

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