如何解决在控制器操作中等待异步方法后,为什么System.Web.HttpContext.Current为null?
在我的ASP.NET MVC Web应用程序中,我的Controller
操作方法之一调用了一些代码,这些代码依赖于从当前HttpContext
获取信息。该代码不是我的Controller
的一部分,因此不能使用Controller.HttpContext
-而是使用System.Web.HttpContext.Current
。 (我知道这是个坏主意,但我无法改变这一点。)
一切正常,直到我在await
操作方法中添加了Controller
。现在,当我随后调用使用System.Web.HttpContext.Current
的代码时,它失败了,因为HttpContext.Current
是null
。
我阅读了一些内容,发现说System.Web.HttpContext.Current
仅设置在正在处理Web请求的线程上。这就说得通了。但是,令我惊讶的是,仅使用await
就足以切换到其他线程。
我的理解是,使用await
不使用ConfigureAwait(false)
(如var result = await myTask;
)可确保使用有效的await
来调用SynchronizationContext
之后的代码在await
之前。
我在精神上将其等同于“在同一线程上运行”-也就是说,await
之后的代码将与await
之前的代码在同一线程上运行(即使{{ 1}}可能正在其他线程上执行)。事实并非如此-Task
前后Thread.CurrentThread.ManagedThreadId
是不同的。
奇怪的是,我看到的行为与this question中描述的行为相反。
我很困惑-是否有人可以阐明(a)在进行任何await
调用之后我是否应该期望System.Web.HttpContext.Current
为空,以及(b)是否有任何方法可以编写代码await
在同一线程上恢复后,以不为空?
解决方法
好的,我在类似问题上发现了this answer。显然,此行为是由ASP.NET的“怪异模式”引起的。 :-(
通过在我的web.config
中添加以下内容,可以确保在同一线程上执行await
之后的代码,从而使HttpContext.Current
不为空。
<add key="aspnet:UseTaskFriendlySynchronizationContext" value="true"/>
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。