3

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

El Che
  • 1,301
  • 3
  • 15
  • 33
  • I don't believe that would be possible without storing your session in database, as changing from v2 to v4 would recycle the application pool and cause your session to be lost. – Brock Hensley Sep 03 '13 at 14:26
  • 1
    The sessionserver is on a separate machine though, so that is not restarted so sessions should still exist. – El Che Sep 03 '13 at 16:15
  • Do you have same machineKey in different versions of .NET? Some other possibile differences when changing .NET: http://stackoverflow.com/questions/686873/allowing-session-in-a-web-farm-is-stateserver-good-enough?rq=1 – Brock Hensley Sep 03 '13 at 18:33
  • Good point. Will check in the morning – El Che Sep 03 '13 at 19:59
  • Yes, same machinekey, and same decryptionkey and we still use SHA1 as algorithm – El Che Sep 04 '13 at 06:37
  • Also, make sure your objects are serializable. See KB 312112 for details. For session state to be maintained across different web servers in the web farm, the Application Path of the website (For example \LM\W3SVC\2) in the IIS Metabase should be identical in all the web servers in the web farm. See KB 325056 for details – Brock Hensley Sep 04 '13 at 12:44
  • See my edit, app paths have not changed and are identical – El Che Sep 04 '13 at 13:14
  • I'm tempted to think that this cautionary note is related. [The state of a UTF-8 or UTF-7 encoded object is not preserved if the object is serialized and deserialized using different .NET Framework versions.](http://msdn.microsoft.com/en-us/library/72hyey7b.aspx). Because the state server is out of process, it's using binary serialization - and the session ID itself is a 24 character string (although strings are stored internally as UTF-16, so I'm not sure if this particular warning definitely applies. – pattermeister Sep 05 '13 at 20:56
  • Thanks, but I don't think this is the issue, since session is not lost if I create the session in app pool of .net 4, and afterwards "downgrade" to .net 2. The proof I have, is that session is lost only when creating session on app pool with .net 2, and then do an upgrade of app pool to .net 4 – El Che Sep 06 '13 at 05:58
  • does the web.config get updated in this process? (the release process) would it be possible this is causing the users to be kicked ?? – Craig Hannon Sep 11 '13 at 14:21
  • Yes it does, but the session part remains unchanged. Config is changed every single deployment though. – El Che Sep 11 '13 at 17:43

2 Answers2

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.

El Che
  • 1,301
  • 3
  • 15
  • 33
1

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.

Alex KeySmith
  • 16,657
  • 11
  • 74
  • 152
  • You may wish to ask this on stackoverflows sister site: serverfault.com as it may garner & warrant the attention of IT pros rather than developers. – Alex KeySmith Sep 12 '13 at 16:37
  • 1
    Awarding this the answer, as your solution is what we are planning to do. Albeit with a small pre release patch to do sticky sessions through the lb – El Che Sep 12 '13 at 17:43
  • Cool, it'll make an interesting blog post. – Alex KeySmith Sep 13 '13 at 08:18