I have faced a problem with Asp.NET Session ID. Whenever there are code-behind changes and moved dll to liver server / if there are any modifications to web.config file, the existing session is is not accessible. The session id is going to reset.
If we use stateserver then we can retain session values. But it is not possible in some shared hosting environments.
Is there any other way to keep session values irrespective of changes?
There's also SQL server based sessions. You may or may not be able to set this up with your shared hosting. But if you can, it works quite well. It has the benefit of being very persistent. Even if the server goes down the sessions will be retained. It's pretty much the only way I'll use sessions.
Here's an article that explains how to set it up: http://faqfront.com/document/sql-server-session-state
With any luck your shared hosting provider can help you with this since it could benefit all of their customers.
Another option is to try to make the site not use sessions. I could be wrong but I think this is what SO does. I don't know specifically on the SO case, but you can read/write from a cookie all the time. This would persist across code changes.
This is actually something I'm getting ready to try to implement in a project of mine to eliminate session timeouts. It was very fresh in my mind so I thought I would throw it out there.
In addition to Sql Server based sessions, you can also store sessions in a service process. That's called out-of-process mode.
You can find an introduction into session state here: http://msdn.microsoft.com/en-us/library/ms972429.aspx
in my tests, session.sessionid is not being reset. but, stored session variables are losing.
i recommend to use a session data table (in db) accessible by asp.net session id. so, application recyclings wouln't affect your session table. because of unchanged sessionid, you can still access exact session variables.
whenever you change the web.config you're causing an IIS app pool to be recycled. when the app pool recycles, any objects stored in session will be lost. the best way to minimize this (without moving to out of proc [so either State Server, Sql Server, or a distributed cache such as memcache or Velocity]) is to simply limit how often you're putting out updates. put them out at "1am" (whenever load is low). otherwise out of proc (Sql Server might be best in a shared environment..but good luck on perf) might be your best bet.