为什么Await后HttpContext.Current为空？

Question

我有以下测试WebAPI代码，我没有在生产中使用WebAPI，但我之所以这样做是因为我讨论了这个问题：WebAPI异步问题

不管怎样，下面是冒犯的WebAPI方法：

public async Task<string> Get(int id)
{
    var x = HttpContext.Current;
    if (x == null)
    {
        // not thrown
        throw new ArgumentException("HttpContext.Current is null");
    }

    await Task.Run(() => { Task.Delay(500); id = 3; });

    x = HttpContext.Current;
    if (x == null)
    {
        // thrown
        throw new ArgumentException("HttpContext.Current is null");
    }

    return "value";
}

因此，我认为第二个异常是预期的，因为当await完成时，它很可能位于另一个线程上，其中HttpContext.Current作为线程静态变量将不再解析为适当的值。现在，基于同步上下文，它实际上可以在await之后被强制返回到相同的线程，但我在测试中没有做任何花哨的事情。这只是对await的简单、幼稚的使用。

在另一个问题的注释中，我被告知httpcontext.current应该在等待后解决。甚至还有一个关于这个问题的评论也表明了同样的观点。那么什么是真的？它能解决吗？我想没有，但我想要一个权威的答案，因为async和await是新的，我找不到任何确定的东西。

TL；DR：HttpContext.Current在Await之后是否可能为空？

Answer 1

是我的测试有缺陷，还是我缺少了一些web.config元素，它可以在等待后使HttpContext.Current正确解析？

您的测试没有缺陷，并且在等待之后的HttpContext.Current不应为null，因为在ASP.NET Web API中，当您等待时，这将确保在此等待之后的代码传递的是在等待之前存在的正确的HttpContext。

Answer 2

正如@Stephencleary所正确指出的,您需要在web.config中提供以下内容：

<httpRuntime targetFramework="4.5" />

当我第一次对此进行故障排除时，我在解决方案范围内搜索了上述内容，确认它存在于我的所有web项目中，并迅速将其排除为罪魁祸首。最后,我想到要在完整的上下文中查看这些搜索结果：

<!--
  For a description of web.config changes for .NET 4.5 see http://go.microsoft.com/fwlink/?LinkId=235367.

  The following attributes can be set on the <httpRuntime> tag.
    <system.Web>
      <httpRuntime targetFramework="4.5" />
    </system.Web>
-->

多伊。

教训：如果您将一个web项目升级到4.5，您仍然需要手动进行设置。

Answer 3

请确保您正在编写ASP.NET4.5应用程序，并以4.5为目标。async和await在ASP.NET上具有未定义的行为，除非您运行在4.5上并使用新的“任务友好”同步上下文。

特别是，这意味着您必须：

• 将httpRuntime.targetFramework设置为4.5或
• 在AppSettings中，将aspnet:UseTaskFriendlySynchronizationContext设置为true。

更多信息请参阅此处。