Why Does XmlSerializer Write to Disk?

I recently came apon one of my recurring peeves: XmlSerializer. It’s one of those classes that just bits you again and again. It has a number of annoying behaviours but the worse has to be it propensity to write to disk. Why? Why, of all classes, would you choose XmlSerializer to perform file IO?

It’s lunacy since the class is typically used in scenarios where you’re in executing from inside a sandbox, like XBAP, Silverlight or other partial trust settings. And then WHAMO your auto generated SOAP proxy… writes to disk!

It just makes no sense. However I know why XmlSerializer writes to disk; because it uses Reflection. Which ’emits’ a dynamic assembly , again, to disk. Which in itself is further lunacy, is it not? I’m dynamically building an object, I know, lets write to disk.

.Net is capable of loading Assemblies from MemoryStreams, I’ve done it, so why default to writing to disk? It’s like the bank teller going to The Vault to get you a fiver: time-consuming and insecure.

Has anyone got a defence for XmlSerializer?  … It better be sturdy 😉

Advertisements

3 Responses to Why Does XmlSerializer Write to Disk?

  1. David Barnhill says:

    I’m not defending XmlSerializer, but I can shed more light on what it’s doing. It’s actually generating C# code and compiling it from what I remember. It isn’t generating an assembly using reflection emit. You can cut down on this behavior by precompiling the serializer assembly. I can’t remember the steps to do this but you should be able to find it in the .Net documentation. Creating a serializer once and reusing it instead of creating one each time it’s needed also speeds things up. You can declare a serializer as static and reuse it from many threads with no issues that I’ve found. If the serializer is being used beyond your control from someone elses code, then you are out of luck though. Luckily Windows Communication Foundation uses it’s own serializer by default that is faster and more disk friendly than the XmlSerializer.

    For high performance code and/or large XML documents I generally fall back to using XmlReader/XmlWriter directly instead of using XmlSerializer.

  2. Thanks for the info David. I’ve had to resort to using XmlReader/Writer on a few occasions and it always felt silly to do so, glad to see someone else has had to do it too.

  3. Mike Pelton says:

    You can use the SGEN utility to pre-build the DLL that XmlSerializer’s trying to create – that way you can use XmlSerializer in XBAP as XmlSerializer doesn’t need to generate code to disk

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: