Thursday, February 18, 2010

What is a TypeLoadExceptionHolder and What Should I Do If I Have One?

Recently at work I was creating a new branch in Subversion for one of our projects when I ran into a little error on one an integration test called "Should_Send_Data_From_File_To_Server":
Object of type 'System.Runtime.Serialization.TypeLoadExceptionHolder' cannot be converted to type 'System.Collections.Generic.List<companyname.framework.persistableobject>'
TypeLoadExceptionHolder? What the crap is that? I tried Binging it, and after pouring through results, found this post by Michael Freidgeim:
Binary deserialization doesn't throw exceptions, but just replace some members(in my case it was enum, that was moved from one namespace to another) with this undocumented TypeLoadExceptionHolder class.
OK, so why was my binary deserialization failing? I wrote up a quick integration test to simply serialize and deserialize a file and it worked fine. But the sample serialized file just wouldn't deserialize in this branch, even though this exact code worked fine in the source branch.

I was nearing my wits end when I realized Michael had already nailed it for me: namespaces. One of the reference assemblies, "companyname.framework", had changed names in this release branch. It used to be "companyname.framework.core". And so the sample serialized file had the old namespace and couldn't properly be deserialized. The mystery is solved.

The moral of the story is Never trust canned data in your integration tests. Always suspect it when sometime goes wrong.

No comments:

All rights reserved. Take that!