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 😉