When Im debugging my application I ask Visual Studio to throw all exceptions in my code. (I do this by checking everything in Debug > Exceptions) It seems like a good thing to have while debugging applications – to know the exceptions you’re getting even if you’re catching them and handling them. This setting in combination with the use of System.Xml.Serializers seems to constantly throw this error in my application:
This gets annoying after a while as my code seems to be perfectly alright, no errors, but this window keeps popping up at this line:
XmlSerializer xmlSerializer = new XmlSerializer(type);
I looked at the error in detail and it seems to be looking for an assembly named My.Namespace.XmlSerializers. Of course there’s no such assembly and the compiler will get a System.IO.FileNotFoundException. The best solution I could Google out was to uncheck the BindingFailure and prevent the exception from showing up every time.
This worked only in stopping me from getting annoyed, whenever that error showed up, but I knew there still was some error and it was being handled somewhere! I had to figure out what was going on…
Enter Reflector (Now a RedGate product. An addition a cool line up of .NET tools)
I have a trial version of Reflector on my machine and this is an excellent opportunity to figure out what in the world is happening in System.Xml.Serialization. I disassembled the entire System.Xml assembly and searched for the keywork ‘XmlSerializers’.
Looks like there is code to generate a custom assembly to handle type passed to the current serializer. Every call to this creates this assembly in a temp location and runs the deserialization through this assembly. There seems to be multiple options for the ‘temp location’ to generate this assembly. Once the assembly is generated, it is delay loaded at runtime. During this the assembly loader searches for all the possible temp locations and each time it fails to find the assembly in one of the temp locations, it throws a FileNotFoundException. This exception is rethrown as a bind failure.
So… I don’t know why the serialization/deserialization logic needs to be this complicated. But, in case of the core .NET library, it just is. I also have noticed that the memory footprint of System.Xml.Serialization classes to be quite big. This whole process of creating a temp assembly probably adds to it. I know there are better solutions for XML deserialization out there. I will soon get onto searching for one and evaluating it against System.Xml.Serialization methods. I’ll add an update to this post when I do find one (eventually…)
In conclusion, System.Xml.Serialization classes and methods are an expensive way to serialize objects to XML or to deserialize XML to objects. This throws a BindingFailure exception as the library internally uses a try catch to handle delay loading a temp assembly. Though this code is internal to the assembly, this error shows up if we enable throwing all exceptions as the delay load is happening in the context of our application.
So, the best solution to avoid (seeing) this error is what’s been suggested by many – in Visual Studio uncheck BindingFailure in Debug > Exceptions under ManagedDebuggingAssistants