We have a system that reads an Xml file containing settings and deserializes it to objects. It has been working just great on our Windows 2003 servers, and has been doing so far many years. We haven't made any changes to the code in quite some time.
This week I needed to add a minor feature to one of the pages, and to do this I brought the code forward from Visual Studio 2008 to 2013. When I tested the application on my Windows 7 workstation running IIS 7.5 everything worked as expected. But when I promoted it to our QA servers a DLL that does the deserializing of an Xml-formatted settings file failed with this exception:
There is an error in XML document (21, 8)...
I've seen this kind of thing before, and it has always meant that there was something goofed up at column x of line y (or vice-versa, whatever). However, nothing has been changed in the Xml file, and in fact it is perfectly formatted. And the code of the Deserializer hasn't been changed, either. It goes like this:
XmlSerializer serializer = new XmlSerializer(typeof(OFM.UserManager.SystemSettings.UMSystems));
serializer.UnknownNode+= new XmlNodeEventHandler(serializer_UnknownNode);
serializer.UnknownAttribute+= new XmlAttributeEventHandler(serializer_UnknownAttribute);
FileStream fs = new FileStream(fileName, FileMode.Open, FileAccess.Read);
SystemSettings = (OFM.UserManager.SystemSettings.UMSystems) serializer.Deserialize(fs);
Now, I have used the XmlSeserializer.Deserialize method before, and as clever as it is underneath the covers, I have found that it is as touchy as hell. In fact I no longer use it, preferring to roll my own deserializer whenever I need one. But I wasn't supposed to be changing code that had been working!
But I couldn't figure out what was going on in time (they needed the change quickly), so I wrote a new deserializer routine and put it into service instead of the old one. It works just fine.
I still want to know what happened, however.
Thing is, I'm going from a Win7 workstation with VS2013 on IIS7.5 to WinServer2003 and IIS 6.0. Also, it appears that I may be taking the application from Fx 2.0 to 3.5.