HttpContext.Current异步任务里面空

本文介绍了HttpContext.Current异步任务里面空的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述

我有一个使用仓库里的方法（ userRepo ）

I have a method that uses a repository (userRepo):

public override Task<IdentityResult> CreateLocalUserAsync(IUser user, string password, CancellationToken cancellationToken) { var task = new Task<IdentityResult>(() => { TUserEntity newUser = new TUserEntity { Id = user.Id, UserName = user.UserName, Password = password }; userRepo.Save(newUser).Flush(); return new IdentityResult(true); }, cancellationToken); task.Start(); return task; }

的 userRepo 对象都有一个使用 HttpContext.Current 的依赖。这两个正在使用ninject来拆分 InRequestScope 。

The userRepoobject has a dependency that uses HttpContext.Current. Both of these are resolved using ninject InRequestScope.

上面的方法被称为MVC中5默认的AccountController 里面的：

The above method is called inside the default AccountController in Mvc 5:

var result = await IdentityManager.Users.CreateLocalUserAsync(user, model.Password);

我已经尝试添加此设置web.config文件：

I have tried adding this setting to web.config:

<add key="aspnet:UseTaskFriendlySynchronizationContext" value="true" />

此外，我肯定使用.NET 4.5。这也是我的web.config：

Also, I am definitely using .NET 4.5. This is also in my web.config:

<httpRuntime targetFramework="4.5" />

这是不可能得到从的HttpContext 开始之前，我的任务，因为的依赖 userRepo 在任务正在使用的信息和两个对象正在使用Ninject解决。

It is not possible to get the information from the HttpContext before I start the task because a dependency of the userRepo in the task is using the information and both objects are resolved using Ninject.

我怎样才能确保 HttpContext.Current 将不能为null？

How can I ensure that HttpContext.Current will not be null?

推荐答案

任务型同步语境在这里适用于来自延续等待：无论你做什么用结果，这将有HTTP的上下文。它的不的，但是，涉及到 task.Start 。涉及到的TaskScheduler,不同步上下文。

The "task friendly sync context" here applies to the continuation from the await: whatever you do with result, it will have the http-context. It does not, however, relate to task.Start. That relates to the TaskScheduler, not the sync-context.

基本上，由工人执行此，你是（在这个过程中，作为一个结果）离婚从HTTP上下文该工人。您必须：

Basically, by performing this on a worker, you are (in the process, as a consequence) divorcing that worker from the http-context. You must either:

• 让你从HTTP上下文和通需要一个的信息到的工人，或
• 请不要使用工人

就个人而言，我怀疑你推到这个工人越来越多。如果你真的想去异步，理想的将是你的回购协议内部支持 *异步方法。这需要比使用线程：它通常意味着体系结构的变化，例如，使用异步SQL方法。从地上写了使用异步和同步上下文感知延续的东西（又名等待）会自动preserve东西，如HTTP上下文。

Personally, I doubt you're gaining much by pushing this onto a worker. If you really want to go async, the ideal would be for your repo to internally support *Async methods. That requires more than using threads: it usually means architectural changes, for example, using async SQL methods. Something written from the ground up to use async and sync-context-aware continuations (aka await) would automatically preserve things like the http-context.

这里最重要的区别是异步 / 等待实施是线性的，但是不连续的，即

The important difference here is that an async/await implementation is linear but not continuous, i.e.

<===(work)==> <===(callback; more work)===> <===(another callback)===>

在这里，为您现有的code可能执行的事情并行的，即。

<==========(original work)=================> <===========(task on worker thread)=============>

的异步 / 等待办法是的基本的线性使得它远远的事实更适合访问的东西如http上下文，因为它知道（右完成）只会有一次一个线程访问它。 - 即使它是不相同的线程端至端

The fact that the async/await approach is basically linear makes it far more suitable for access to things like http-context, since it knows that (done right) there will only be one thread at a time accessing it - even if it isn't the same thread end-to-end.