1

I have a weird behavior, which I don't even know how to diagnose.

Some properties during de-serialization are not set (null), even though I clearly see them in the (just-produced) XML document. The XML document looks well structured and symmetric with regards to similar types of objects.

It looks like it sets values up to a certain point, then stops setting values and beyond that ignores all other data.

Just to point out - the last value it sets correctly is an object of type that contains another object for which, because of issues of singleton-like de-serialization, I had to implement IXmlSerializable. I'm pointing this out since it could hint at some bug, although I can't figure out what it could be.

EDIT: I read some articles about retrieving the serialization assembly and code. For some reason, it only outputs the .dll and the .pdb file, but not the .cs, as the articles mention

Thanks

Community
  • 1
  • 1
New Dev
  • 48,427
  • 12
  • 87
  • 129

1 Answers1

1

Ok, solved! This is a two-part solution:

1) Enabling diagnostics

First, in Visual Studio 2012 (or perhaps more correctly in .NET 4.5), it's not enough to set the following in the app.config for XmlSerialization diagnostic:

<system.diagnostics>
    <switches>
      <add name="XmlSerialization.Compilation" value="1" />
    </switches>
</system.diagnostics>
<system.xml.serialization>
    <xmlSerializer tempFilesLocation="c:\foo"/>
</system.xml.serialization>

You also need to add the attribute useLegacySerializerGeneration="true" to produce the auto-generated .cs file of the serializer

<system.diagnostics>
    <switches>
      <add name="XmlSerialization.Compilation" value="1" />
    </switches>
</system.diagnostics>
<system.xml.serialization>
    <xmlSerializer tempFilesLocation="c:\foo" useLegacySerializerGeneration="true"/>
</system.xml.serialization>

2) Pitfall in IXmlSerializable implementation

Make sure that XmlReader (when it's in the ReadXml(XmlReader reader) method of IXmlSerializable) is on the StartElement of the next element when you're done with it, not on the EndElement. In other words, make sure to call:

reader.ReadEndElement();

Because of it, xml deseralization reader got skewed data and read all the elements in the wrong places, producing nulls.

New Dev
  • 48,427
  • 12
  • 87
  • 129
  • This still works as of Visual Studio 2017. Note that when adding `tempFilesLocation`, intellisense will add a squiggly and say "tempFilesLocation attribute is not allowed." Ignoring this and rebuilding allowed me to debug into the *.cs files. Also, the `randomname.cs` files that I needed didn't show up in the temp directory until I hit the breakpoint where the deserialization was happening. After doing this I was able to debug through the code generated via the wsdl and determine the source of the issue. – dunc May 21 '18 at 20:18