52

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?

Steve H.
  • 3,283
  • 4
  • 24
  • 32
  • You can avoid having the runtime create a serialization assembly on the fly by pre baking it with SGEN (not the funnest tool to use however). Just a thought, though I am not sure why you are getting this error. – Nick Larsen Feb 05 '10 at 18:41
  • What is the root namespace of your project called? – SwDevMan81 Feb 05 '10 at 19:10
  • Yes, the namespaces are different. Since I don't want to give away anything could get my bum sued, let's just say the application's name space is "Namespace1" and the serializable objects are in "Namespace2". – Steve H. Feb 05 '10 at 19:21
  • Check .NET version of yours CustomXMLSerializeObject.XmlSerializers.dll it should be same as your project. Check this: https://stackoverflow.com/a/52848813/5639198 – Sashus Oct 17 '18 at 06:52

4 Answers4

70

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
  • 48,814
  • 22
  • 151
  • 184
  • 8
    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. Feb 05 '10 at 20:12
  • 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 Feb 05 '10 at 20:16
  • damn, it's time consuming to realize that a frightening horrible message is just nothing in the end. – v.oddou Oct 11 '13 at 13:22
  • 4
    Sorry, but I just can't accept turning off notifications to get around being told something is wrong. What if the notification isn't as relatively benign as this, but something that causes unexpected behavior, or even an otherwise unexplained crash? No. What needs to happen is to find out why this is occurring and handle it there, not just ignore it and hope all else will be ok. See my answer below. – ouflak Nov 01 '13 at 07:47
  • _based on your exceptions that you are choosing to monitor._ BOOM! That's it for me. Ty! +1 – ray Jul 07 '14 at 19:12
44

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.

Lin Song Yang
  • 1,936
  • 19
  • 17
  • A good solution, but what if I have to pass an array of extra types to the `XmlSerializer`? Adding more types here will just create more `XmlSerializer`s and not include the extra types, of course. – Martin Braun Aug 03 '15 at 09:59
  • This was the only solution that has worked for me, but I can't understand it. Anyone can explain me what's the difference between creating the XmlSerializer in this way and instantiating it with the "new" syntax that's shown in the question? – EAmez Mar 31 '16 at 11:33
  • 1
    @al2suarez I was curious about your comment, and wanted to put numbers to it if it was true. I created a .Net fiddle here https://dotnetfiddle.net/LgwCkh comparing the two methods, and I found, on average, that creating a serializer using `FromTypes` is about 10 times slower than using the constructor. If you are creating a lot of serializers that could be an issue. – TJ Rockefeller Apr 07 '17 at 14:20
4

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.

Lucas B
  • 11,793
  • 5
  • 37
  • 50
0

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.

ouflak
  • 2,458
  • 10
  • 44
  • 49
  • 1
    Sounds promising but doesn't work, I still get System.IO.FileNotFoundException – Grant Nov 06 '13 at 03:02
  • 2
    Just curious. You're saying that the BindingFailure is gone, but you are now getting the FileNotFoundException? Is the file (or files) the same as the one proclaimed missing in the BindingFailure? If so, I think you must have a spurious reference somewhere still lurking, or there is something else hidden away in the mysterious abyss of your assembly that is unsearchable by us mere mortals, that this scenario doesn't cover. – ouflak Nov 06 '13 at 11:50