Although the .NET 2.0 Provider Model offers three built-in possibilities for persisting the session context information, there exists frameworks which limit the choice to the InPronSessionStateStore.
One of such frameworks is the Visual Web GUI Ajax framework designed to fill the gap between Windows.Forms and Web.Forms programming. The VWG framework looks very, very promising, however I feel that its development slows down a bit.
Nonetheless, the main idea of VWG is dumb client, allmighty server where the interface is rendered in the client's web browser and the application logic is executed completely on the server.
There are few limitations and one of them is the session state management - the session context collects much more data than the usual Web.Forms session does. Since VWG objects are not serializable, the SqlServer session state store cannot be used and what I immediately though about was: how much data is exactly stored in the session context?
To be able to inspect the session store it would be perfect to just override the InProcSessionStateStore. However, the class is internal. The idea below is to build a custom session state store which uses the InProcSessionStateStore internally but makes it possible to put custom logic into the session store-retrieve pipeline.
Two critical methods are GetItemExclusive and SetAndReleaseItemExclusive. This is where the custom code can be injected into the pipeline. The code can, for example, log the content of the session store or modify it somehow.
Can I then make my own custom serializer and store the session context in some persistent storage from the wrapped inproc store? you would ask.
Good question. I was not able to find a generic solution to the serialize non-serialized objects problem. The GeneralSerializableAdapter solution proposed here is probably a step in the right direction, however it does not serialize collections correctly (or when it does after you tweak it, it serializes far too much!) neither it is able to serialize non-serialized properties.
If you are able to write a generic serializer which would be able to serialize objects which are not marked as serialized (and do not contain parameterless constructors), please feel free to go a step further then I did and extend the inproc state store wrapper with the generic serializer.
Here is the code: