The wacky world of serializers

 Recently I’d set my debug exception handling to catch pretty much every exception thrown and I kept seeing a rather strange error…
System.IO.FileNotFoundException occurred
  Message="Could not load file or assembly myType.XmlSerializers"
What was odd about this error is that although the type in question was being serialized it wasn’t overloading any serialization code, so why the exception? The question did the rounds of the development team and a colleague discovered the truth. It turns out that as an optimization .net searches for a special optimized serialization version of the type, based on the type’s names. If it finds it, it uses it. If not a file not found exception is raised and then automatically handled and the default serializer is called into play. What I find odd about this concept is that in order to use an optimization, that I would have to write anyway, the framework makes an expensive disk access followed by an exception. So the effect is that if I don’t implement the optimization I get an extra performance hit!

Leave a Reply

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

You are commenting using your 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 )

Connecting to %s