Replacement for XML Serialization

Question

I have code using XmlSerializer to serialize/deserialize a data structure for persistance. I've read and heard in several places here on StackOverflow that XmlSerializer is one or more of:

• Bad
• Poorly supported/implemented
• Possibly won't be supported into the future

My question is two-fold; is any of the above true, and if so, what alternatives exist? For my purposes, XML works very well, and I would like to keep that much constant, but everything else is open to change.

EDIT: If you want to suggest something other to XML, I'm open to it, but it does need to be human-readable.

Answer 1

If you can use .Net 3.5 (preferably SP1), I'd look into the DataContractSerializer. Although it is less configurable than the XmlSerializer, it's faster, easier to work with (at least in my experience) and more portable (i.e. for web services). SP1 changed the default behaviour of it to be opt-out, so you can serialize any class without having to explictly define attributes on everything you need to serialize.

I would recommend thoroughly reading the documentation on it though before investing in it as a change. Depending on how customized your serialization is, it may not work for you.

Answer 2

XmlSerializer is perfectly supportable, but has some glitches;

• relatively slow; but usually this is still fast enough
• only supports public members; can be a pain
• requires write accessors lists - just ugly

However, I expect it to continue to be there for a considerable time; IMO, it is BinaryFormatter that has the real problems (when used for persistence).

I'm very biased (since I'm the author), but I'd choose protobuf-net; a binary serializer using Google's "protocol buffers" wire format; fast, portable between languages/platforms, very small output, version tolerant, etc (and free, of course). Clearly not xml, though - so not human readable.

Answer 3

jSON is much more faster than XML. You can use Json.NET to read it. It has built-in serialization.

http://james.newtonking.com/pages/json-net.aspx

Answer 4

As far as the XML Serializer, there's "supported", and there's "supported".

An increasing number of Connect bug reports on the XML Serializer are coming back acknowledging bugs, and stating that the bugs will not be fixed.

I'm sure that if you ran into a security-critical bug in the XML Serializer, that it would be fixed. However, I think it's unlikely that other bugs that are not as critical will ever be fixed.

Answer 5

I'm going to take an alternative view:
XmlSerializer is supported, its behaviors are known, and it works well. It is not "bad". It is very general, well documented, has lots of examples. The performance is probably very good for what you need. It probably does what you need.

There are some people who have particular needs that are not addressed by the XmlSerializer. From those requirements we get things like protobufs, DataContractSerializer, and other options.

But XmlSerializer is still very general and probably the most widely applicable serializer in town. It's still probably the safest bet for serializing content.

---

As to support...
MS may be slowing down on fixing bugs. I compare this to WinForms. WinForms is no longer the primary UI framework being pushed by Microsoft. But it is still mature, works well, performs well. XmlSerializer is the same.

As for support into the future. MS has a 5+5 support policy - they support a product for 5 years after its release, and then you can buy 5 years additional support for it. The .NET Framework is not the supported "thing" - it is the Windows OS that includes .NET that is supported. Windows 7 will include .NET 3.5 (I think the version is 3.5?) and so everything in .NET 3.5, including WinForms and XmlSerializer, will be "officially supported" for an additional 5 years, starting in October or whenever Win7 is released. If it is .NET 4.0, then anything in 4.0 (including, still, WinForms and XmlSerializer) will be supported for 5 years. The 5-year clock restarts every time a new product ships with .NET.

Looking at the VB6 Runtime, it was originally shipped with Visual Studio 6, in 1998. It has been included in Windows since then, including Windows Server 2008 R2, released this year. So the VB runtime will be supported at least until 2014. That's 16 years of mainstream support, at least.

You have nothing to worry about as far as official support. This isn't an open-source project you're talking about. This isn't a stopgap offering like WSE or the SOAP Toolkit.

It's true that there are degrees of support, and older .NET APIs ratchet down in priority as the newer ones are launched and promoted. But the older ones are presumably more stable, by the time they plateau. You're totally safe.