Ok, I take the hint, but my story differs:

First version of our app at the final stage of development, recently it was on preview 2 and I tries to upgrade it to preview 4 (to use ActionResults, HandleError Attribute instead of redirects n etc.). Controllers was application-scope from the beginning of development and I don't want (yes, agree that I probably can in most cases) change lifecycle of controllers now just for avoid this problem.

Hello. I'd also vote for a controller per request approach. On the one hand, what you probably need to do is change your controller factory so that it will also set up the tempdata and tempdataprovider properties. On the other hand, to me this seams like a really bad idea because you might end up trashing the processing of a ongoing request when you receive a new one. If you ask me, I'd refactor the code so that you'd get a controller per request that would consume a global application that had the "static" info you want to share between all the requests.

Well think about it for a second and you'll realize that if it worked at all in Preview 2, it was very lucky, and probably fragile. Remember that the HttpContext itself is created once per request by ASP.NET. With the TempDataProvider, you are passing a reference to the HttpContext.Current in request #1. Now request #2 comes along to the same controller instance that you have scoped to the application, but it's still pointing to the same TempDataProvider (and thus the same HttpContext instance) from request #1, which is no longer valid.

If you want to have your controller application scoped, you have to make sure that all its dependencies are repopulated on every request. The lifecycle of your controller is now a mismatch with the lifecycle of its dependencies. This is not a flaw in Preview 4, this is just the way that ASP.NET works.

Thanks for all the answers. It did solve my problem. I just forgot to put one specific controller transient.

One remark though: the error message that you receive ("The provider requires the session state to be enabled") could be somewhat more clear. It could very well be that session state is correctly enabled but still you have a problem, due to for example singleton controllers.

hello. well, how could they guess that you're using singleton controllers?

 I am not saying that they should guess that. I am just saying that there could be other reasons for the error than the session state that is not enabled...