WTF: "Soap Serializer does not support serializing Generic Types" ??

So, there you are, with your shiny new .NET 2.0 generic collection using library, trying to push some objects over the wire via remoting. Works great, well, if you use the BinaryFormatter that is. Try using the SoapFormatter, and you're in for a big surprise: Soap Serializer does not support serializing Generic Types.

I couldn't believe my eyes. So of course, I googled and I ran into this thread on forums.microsoft.com. Let me quote what an MS employee posted there:

[...]We have decided not to invest in any significant new feature work for the SoapFormatter in Whidbey.[...]
And another employee:
the SoapFormatter is and will continue to become less important as time passes. If you need an Xml projection of a CLR type, the XmlSerializer is an excellent option until Indigo ships.

I can't draw any other conclusion than: "Starting from .NET 2.0, stay away from the SoapFormatter, or you'll burn your hands sooner or later". This decision of Microsoft is very unfortunate, to put it nicely. The reason for that is that if you write code which should be remotable, you have to implement ISerializable on every class with generic serializable members and after you've done so, that implementation has to migrate any generic type first to a non-generic type (Hashtable, Arraylist) before serialization and in the case of deserialization, it has to migrate the data back to generic types. This, well, sucks big time because the BinaryFormatter can handle generic types just fine, so if the developer uses the objects with a BinaryFormatter, the serialization is unnecessarily slower due to the conversion, left alone the extra work of implementing ISerializable on every class with generic typed members.

The alternative is of course to simply not use SoapFormatter when using .NET 2.0 code. I simply can't understand why Microsoft didn't update SoapFormatter for usage with Generic types. It's not as if Indigo, or what's its name today, is available at the moment. So, if you're doing remoting, do yourself a favor: already start using the BinaryFormatter, so you won't run into this problem later on, or of course avoid Generic Types (yeah, like that's an alternative... )

4 Comments

  • I have to ask -- why are you hung up on the SoapFormatter? The SoapFormatter does not provide significant advantages in terms of interoperability or performance. It's not the right way to build web services and it's a pretty clunky way of building remoting apps. The binary formatter is well-suited for tightly couple remoting apps, and if that's what you're building why not just use it?



  • Personally I don't care what formatter is used, but as I write a library which is used by others, I can't make the decision for them. If someone now uses my library and the soapformatter on .NET 1.x, it works ok. If they upgrade to the new library it won't because of this.

  • Well yes that is true. There were talks of deprecating SoapFormatter around the beginning of .NET 2.0. I think atleast until Beta2, even the reference of SoapFormatter was in a seperate dll (unlike 1.1), So I'm not shocked that this has become the stepchild.



    Frankly - I'm okay with that :).



    Now only if they would fix the XmlSerializer and we could all get along.

  • Hi Frans, personally I agree with Steve but I also understand your point of view. Probably Microsoft did not invested on SoapFormatter because XmlFormatter should be the "future SOAP Formatter".

    In fact XmlFormatter serializes and deserializes generic collections.

Comments have been disabled for this content.