One of the good (and the bad) thing about working with ASP.Net Webform is the fact that it tries to be stateful. Alot of the plumbing code involved in persisting session between postbacks is already done for us. As you might already know there are different ways of persisting session; inproc, outproc and sqlserver. I will not cover the basic differences between the 3 approaches. What I will cover in this post is the fact that why I would never use inproc session! ever! (well amost).

So the key distinction in writing code for web app that uses outproc or sqlserver session state management to inproc is the fact that you need to ensure that all the object persisted in session is serializable.

[Serializable]
public class ThisWillBeStoredInSession
{
  public string Name {get; set;}
  public AnotherSerializableObject someObject {get; set;}
}

It make sense, right? To store a piece of information outside its application's own memory allocation, the information needs to be in a serialized form.

Alot of team have fall into the trap of using inproc session as it's the default and easy to get start with. But as soon as they get to a stage where the app need to scale out, these teams will suffer from having to go through each of the classes and mark them as serializable. The developers will not know whether they have left something behind until runtime.

It's crucial then, to always start a project with outproc session. This way, one will always be forced to be discipline to mark each clasess that will be stored in the session as serializable. In production you can switch it back to in proc session if performance becomes an issue (I would probably question why this is the case in the first place anyway-you're probably relying to much on session vars).

Consider outproc than inproc despite the performance hit
What outproc and sqlserver session state gives you is the ability to deploy the latest version of the web app without interrupting user session. This is important in current climate of constant beta application. You want to be in the position to be able to constantly deploy stable build to production without risking interrupting the users.