Followers of the IHttpHandler

Viewstate Serialization, one more time!

Note: this entry has moved.

I just read Scott Mitchell’s article about viewstate where he’s explaining how viewstate serialization works and he’s saying:

“…The LosFormatter can serialize any type of object that can be serialized by the BinaryFormatter class…”

Watch out! That’s partially wrong. That is not complete and might lead you to believe that you need to make your type serializable by the BinaryFormatter in order to be able to store it into viewstate: that’s not true. As I explained in a previous post the LosFormatter will try using an associated type converter *before* getting to a BinaryFormatter. So, a type that is not serializable by a BinaryFormatter can still be serialized by the LosFormatter. It’s a real pity that none of the info that I’ve been detailing on some of my latest posts got mentioned into that article :-(

The reason I’ve been sharing this viewstate low-level details is because I couldn’t find them anywhere else on the web… and there is lot of misconceptions about how this really works, you can easily notice that by browsing the public newsgroups… Hey, even the Mono guys got it wrong at first but after I shout they quickly fix it.

Mono Breaks Your Viewstate

Note: this entry has moved.

There is a notorious difference in the logic used by the viewstate serializer when handling non-optimized types that may cause your code to break when running under Mono’s ASP.NET: they never look for an associated type converter and directly pass any non-optimized type to the BinaryFormatter (ouch!).

You may say “ok, that’s just an optimization thing; I will get a larger viewstate and will pay some extra processing cost, but why is my code going to break?”

Suppose you’ve a Customer type you want to store into viewstate and you’ve coded a CustomerConverter type converter for it:

[TypeConverter (typeof (CustomerConverter))]

public class Customer {

}

This is all you should need to store an instance of Customer into viewstate.

Under Microsoft’s implementation it will run just fine: the serializer will get the associated type converter and use that for serializing the Customer instance.

Under Mono’s implementation things will go bad because the serializer doesn’t use a type converter if one is available and directly passes the Customer instance to a BinaryFormatter. Of course the Customer type is not ready to be serialized by the BinaryFormatter (it is not marked with the Serializable attribute, it doesn’t implement the ISerializable interface) and that’s why a SerializationException exception will be thrown.

Mono team: this should be really easy to fix and by doing so Mono will be more compatible with Microsoft’s implementation, which I suppose is one of your goals :-)

I’ve already filled a bug against the serializer (#59495), let’s see how much luck I get…

UPDATE: Within hours after being submitted the bug is now fixed, cool!