views:

1163

answers:

2

As you know, in ASP.NET, you can store session data in one of following three modes:

  • InProc
  • Session State
  • SQL Server

For InProc mode, you can store any kind of data objects even it's not serializable. However, in Session State and SQL Server modes, you can only store serialized data.

In my project, I have a ready made portal which use "InProc" mode to store its session. I need to use Session State instead due to some scalability and failure handling issues.

The problem that this portal is internally storing unserialized objects in the session context (i.e The stored objects doesn't implement ISerializable interface). I have no access to their code. Is there any work around so that I can be able to store the session objects in State Server without changing their code. I still have access to their web.config file if this would help in any kind.

+1  A: 

AFAIK, the simple answer is no. If you don't mind changing your code, you could inject a wrapper object between the actual object and yours, and make your wrapper deal with serializing the wrapped object (essentially as a serialization surrogate) - but by then it would almost be easier to simply re-write the code...

What sort of objects are they? Typically, objects for session-state would be simple data classes, so there shouldn't be too much issue serializing them?

Marc Gravell
Actually, we don't have access to the code as it's a third party .NET portal. We can only make changes in the web.config. Regarding your comment, can we include a wrapper as an external assembly/DLL and make changes to web.config to use this wrapper for object session storage?
mnour
Not that I know of; you would have to change the page code. So if you don't have access to that, you're a bit scuppered.
Marc Gravell
A: 

Serialisation creates a representation of the object that can be stored and read to re-create the state of the object.

If an object only contains value types then you may not need to implement ISerializable, but only need the [Serializable] attribute.

To make this response more helpful or direct to the question at hand:

You cannot serialise an object that hasn't been delcared in some way as serializable. Any other generic way of re-creating an object might result in the object not having the same state as it had before it was 'serialized'.

As mentioned by Marc, you could do it by creating your own serializable 'wrapper', but you would need to be very familier with the object in question, and the object would need to have methods that would allow it to be re-created in such a way.

Ady
can someone explain the down vote? My point is valid.
Ady
I think the answer didn't resolve the issue.
mnour
The -1 wasn't from me, but I'm guessing that since the code can't be altered, it doesn't matter whether it is ISerializable or [Serializable]. That said, I'd agree your point is valid, so I'll +1 it to even things out ;-p
Marc Gravell
@mnour - hmm; I might drop a line on user voice... it might not have helped per se, but it wasn't actively unhelpful either... maybe the tag should be re-captioned to the active "unhelpful", rather than the neutral "not helpful". (if you see the difference).
Marc Gravell
Yeah.. I see the point..
mnour
Hi Marc, thanks for the up. I've updated my response to try to be more relevant, it won't solve the issue though. As you've mentioned, and I agree the issue cannot be solved. Have an up from me, lol.
Ady
Actually, references should work with [Serializable] too, as long as every object in the graph is serializable.
Marc Gravell