ASP.Net Inproc session restarted after markup change in VS2012

Question

I upgraded my development machine to Windows 8 and Visual Studio 2012.

I'm testing my ASP.Net applications (also upgraded to .net 4.5) on a local IIS.

One thing that is annoying me, that hasn't been this way with my last configuration (Windows 7, VS 2010, .net 4.0), is that InProc-sessions are being restarted after changes in markup files.

Example: I'm logged into my local ASP.net application, make and save changes in a *.ascx file, refresh my webbrowser and the session is gone.

How do I turn off the session restart issue?

Edit: I tried to repro the issue with the new VS 2012 Web Application project template, removed unnecessary content and couldn't repro this issue.

However, in my real project the issue still remains: Changes to an aspx or ascx file result in the Application_Start event being fired.

I also stripped down the web.config in my real project to the bare minimum to look like the one in the new project, but that didn't allow me to remove the bug either. Things I commented out in the web.config were DevExpress Controls, custom healthMonitoring, IIS UrlRewrite 2

Applicationpool as Integrated, v4.0 with NetworkService as Identity

Answer 1

I'm not going to try to take the credit for this but the answer is buried in the 11th comment on the original question by @Anand:

Add this key in web.config:

<appSettings><add key="PageInspector:ServerCodeMappingSupport" value="Disabled" /></appSettings>

and the problem goes away. VS becomes far more responsive too. Only downside is you lose the server-side trickery from Page Inspector.

Hopefully MS will provide a fix soon..

Answer 2

The problem here is your application is doing a dynamic compile which means any changes to the markup files will cause the application to restart. Any application restart, as you know, will dump the InProc session.

A "Web Application" on your local template is set differently so it isn't restarting the whole application. There are advantages to having precompilation though.

There's a couple of ways around this.

Why this is happening

ASP.NET 4.5 allows you to run "web pages" side by side with "web applications" by default. This is likely what's causing changes to an aspx to fire a precomilation (which "web pages" have to do every time there is a change). More info here: http://msdn.microsoft.com/en-us/library/dd547590.aspx

There is also quite a few changes to optimise the web server in the new version. You can see details of those changes here and they also can explain the change when you upgrade. http://www.asp.net/vnext/overview/aspnet/whats-new

The solution is still the same regardless and updating single aspx files on the fly is not recommended. If it's unavoidable, then restart will have happened eventually on any setup so it's worth using one of the below solutions anyway.

Solutions

Compilation Mode

Check the CompilationMode in your web.config. For more info check out this post http://www.campusmvp.net/compilationmode-avoiding-aspx-page-compilation-to-improve-scalability-in-sites-with-thousands-of-pages/

This can be set on a server level too so you can get differences by environment.

Session State Mode

You can run your session state in StateServer mode or using Sql server. The ASP.NET state server will be sitting on your server if .net is installed and just needs to be set to auto start. You can then just switch it in the config.

<sessionState mode="StateServer" useHostingIdentity="true" cookieless="false" timeout="120" stateConnectionString="tcpip=127.0.0.1:42424" />

We always run using the ASP.NET state server for development and in many cases in production. I find when testing long user pathways (like a form wizard with many forms) it's very annoying to have session blatted every time you rebuild. That will also mean you don't lose session on app restarts.

You can also use SQL server in the same way.

NOTE: You must remember that if you are serialising classes into session state and you make changes, you will need to manually restart the state server or you'll get serialization errors. This is very rare, but just to be aware of in production environments.