MVC4 (not WebAPI) controllers using async/await - per-request lifecycle?

Jul 31, 2014 at 9:25 AM

I have a controller that is under MVC4 (using the regular Controller base class) but has async methods:

public async Task<ActionResult> Index()
    var result = await GetContentAsync();

    return Content(result);
So I am using async/await, but not Web API.

Looking at it mentions the difference between Web API and Web requests.

In this case, its a Web Request, but does use async/await so there is some thread/context flow happening.

However, .NET 4.5 does properly set the HttpContext.Current property before/during/after the context flow (unlike .NET 4.0) as long as the "target framework" is also 4.5 (see ).

For example, other operations I rely on with HttpContext.Current being the same before/during/after an async operation is currently working under this system.

Given this; should I still use the Web Request, or Web API Request lifestyle? I am confused about any potential downside to using Web API lifestyle even under regular Web context.

Thank you
Jul 31, 2014 at 9:43 AM
Edited Apr 3, 2015 at 2:51 PM
The main difference between Web API and MVC is that Web API can run outside IIS and thus outside the context of a web request. This is the most important reason why there is a Web API request. For MVC, even for async operations, under normal conditions you can expect the HttpContext.Current to be there and this means that with MVC you can simply use the WebRequestLifestyle

Please see documentation section for more information.
Marked as answer by dot_NET_Junkie on 8/11/2014 at 12:10 PM
Aug 1, 2014 at 6:42 AM
Thank you.