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

Answer 2

Use the following method to construct your xmlSerializer instance will fix the problem:

XmlSerializer s = XmlSerializer.FromTypes(new[] { typeof(CustomXMLSerializeObject) })[0];

then, you don't need to turn off the exception handlings.

Answer 3

According to MS VS 2010 Feedback this is how it was designed. In order to prevent this exception and prevent a slow-down during run-time execution you need to generate a XML Serializer assembly.

There are three tools I could find: Microsoft SGen , XGenPlus and Mvp.Xml.XGen . As of this post, unfortunately, none of these has been updated since 2007.

Answer 4

Alright I've found a solution. I never could accept turning off exceptions as an answer. Just seems somehow wrong....

What seems to be happening is that in previous assemblies, or previous versions of your current assembly, certain references were used externally. Even though your code may have long since abandoned those references, the names are still, some mysterious somewhere, being searched for in the assembly.

Go to your AssemblyInfo.cs files and find ThemeInfo:

[assembly: ThemeInfo(
ResourceDictionaryLocation.ExternalAssembly, //where theme specific resource dictionaries are located
//(used if a resource is not found in the page, 
// or application resource dictionaries)
ResourceDictionaryLocation.SourceAssembly //where the generic resource dictionary is located
//(used if a resource is not found in the page, 
// app, or any theme specific resource dictionaries))]

Change the first location to 'None':

[assembly: ThemeInfo(
ResourceDictionaryLocation.None, //where theme specific resource dictionaries are located
//(used if a resource is not found in the page, 
// or application resource dictionaries)
ResourceDictionaryLocation.SourceAssembly //where the generic resource dictionary is located
//(used if a resource is not found in the page, 
// app, or any theme specific resource dictionaries))]

And keep your exceptions turned on! I will be posting this answer to various questions of this similar nature.