在维护会话的同时将Web场迁移到asp.net的运行时版本4

Question

We've migrated our webapplication from .net runtime 2 (v 3.5) to .net runtime 4 (v 4.5) and I have a question for deployment. Our sessionstate server is a "stateserver", and runs aspnetsession from framework 2 on a separate server. When we deploy and upgrade the application pool to .net 4 to one of our webservers in test, it seems that the session expires or is dropped somehow as we're redirected to the logon page of our application.

Is there any way of deploying our new version of the app without our users losing session in the process? Are the sessioncookie created by application pools runnning in .net 2 not compatible with .net 4? I cannot see anything about this in the breaking changes whitepaper

Edit: Application Path of the website is the same, it has not changed for this version of our application, and we have done "no-downtime" deployments (users don't notice new version and are not logged out) for 5-6 years with approx 50 releases.

Edit2: The opposite is not true: Creating session in an application running .net framework 4, and then downgrading to .net 2 does not break the session. The opposite is true, however.

In advance, thank you for any pointers

Answer 1

After talking to MS pro support and a prominent member of the community who talked to the asp.net team, the fact that the sessions are not compatible between the app pool versions is by design. It´s also not regarded as a bug or a breaking change by Microsoft, although I´m tempted to disagree. In conclusion - my findings were unfortunately correct and our future release will need some extra operational work to be as smooth as can be.

Answer 2

How about load balancing the farm to create "sticky sessions" to stick existing sessions to machines running .net 2.0 and any new sessions to machines running .net 4.0.

Of course this depends on whether your project will withstand running 2 different versions of the project in production at the same time.... As I'm guessing that not only have the .net versions changed but also underlying code in your project. For example will people modifying data in the database from 2 different versions of your project have an impact.

Thus considering it a problem of running multiple versions of your own project, rather than of .net versions' sessions. Looking at it in this angle may make it an easier problem to solve ... or much more difficult :-) depending on your project.