views:

402

answers:

1

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?

+2  A: 

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

SwDevMan81
Le sigh... Yes, I do have it sent to break when they are thrown for debug purposes. I guess I'm just diappointed that exception handling is being used as a flow of control substitute.
Steve H.
Yeah, I ran into this problem a while back when I was running stuff through Windbg and noticed this error. It really should be a simple fix, but it doesnt look like anyone has fixed it. The only work around is to disable that exception and its kind of a crappy work around
SwDevMan81