.net - C# XmlSerializer BindingFailure

Question

I get a BindingFailure on a line of code using the XmlSerializer:

XmlSerializer s = new XmlSerializer(typeof(CustomXMLSerializeObject));

The assembly with display name CustomXMLSerializeObject.XmlSerializers' failed to load in the 'LoadFrom' binding context of the AppDomain with ID 1. The cause of the failure was: System.IO.FileNotFoundException: Could not load file or assembly XMLSerializeObject.XmlSerializers, Version=1.4.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.

The error is quite long and goes on to explain pre-bind state information and the places it looked to try and find the file.

The custom object I am trying to desrialize is relatively simple - just a bunch of private integers and strings that have public accessors. I do have a private variable that is another custom serializeable class but that one has nothing but private strings with public accessors in it.

The awkward part? This only happens when I deserialize. That line of code runs fine when I serialize the object. It works fine and the object gets deserialized and populated perfectly. Don't really notice any loss of performance or long loading time.

What exactly is this warning (not an error or exception, program runs fine afterwards)? Why does it happen? How do I prevent it without simply disabling the warning?

Answer 1

According to Strange XmlSerializer error:

This exception is a part of the XmlSerializer's normal operation. It is expected and will be caught and handled inside of the Framework code. Just ignore it and continue. If it bothers you during debugging, set the Visual Studio debugger to only stop on unhandled exceptions instead of all exceptions.

Its probably being caused based on your exceptions that you are choosing to monitor.

Can you tell me how your exceptions are setup: Debug -> Exceptions

If you uncheck the "Thrown" checkbox for the BindingFailure under the Managed Debugging Assistants the exception should go away. Or if you dont want to do this, you can just continue since this exception is by design