views:

101

answers:

4

Are there any tools out there for helping to debug / check the xml serialization process?

For instance, suppose an item is marked as internal instead of public. There is no compile time error message, nor a runtime error message. If you set a breakpoint and step into the serialization process, the item is just just skipped. In other words, it is often hard to find these types of problems. A debug tool would allow you to step through the process and provide some feedback e.g. encountered this attribute, iterated through properties and didn't find a corresponding public one, skipped. Another option would be a check tool to examine all the classes with xml serialization attributes to make sure they are accessible and have set methods, etc.

+1  A: 

What do you mean "an item". If a type is internal, you should see an error message. The outermost exception isn't usually very helpful, but trace down through .InnerException to the bottom and it usually spells out exactly what the problem is.

If a member is entirely internal, then sure - it will be skipped.

IMO, unit /integration tests are your real friend here - the desired output from serialization is ultimately outside the compiler, so it doesn't matter whether you get a compile-time message if the output doesn't match what you expect. What I mean here is: do the serialization and compare to an expected output file. Ditto input.

For example, trying to serialize:

[XmlRoot("Node", Namespace="http://flibble")]
public class MyType {
    [XmlElement("chileNode")]
    public string Value { get; internal set; }
}

gives (at runtime):

Unable to generate a temporary class (result=1). error CS0200: Property or indexer 'MyType.Value' cannot be assigned to -- it is read only

which is pretty specific.

Marc Gravell
For example, a collection of objects with the collection set to internal and the type set to internal does not generate a compile time or runtime error with the xmlarray attribute on the collection and a xmltype on the object type. A compile-time error message is generated when you just set the ObjectType to internal, but that is because the collection has more limited access than the type.As another example, an accessor set to internal with the XmlAttribute attribute also does not generate an error.Further, though this is obvious, a missing set; method does not cause an error.
Tim
Just to clarify: this is assuming that the xml file is formatted correctly. That is a whole other problem. I have to get the code to correctly process properly formatting xml before I can tackle improperly formatted xml!
Tim
A: 

I am not aware of any existing tool, but you can scan classes with reflection. You can use reflection to see the code produced by serializer.

Vladimir Lifliand
A: 

What you could do here is utilize the SGen.exe tool from the MS Visual studio environment.

By running this tool over your assembly which contains the serilizable types, it generates all XMLSerializer versions for you in a library called "{original-library-name}.XmlSerializers.dll."

You'll have to run it as commandline tool (as post-buildstep maybe?) since the option that is available in the 'project-options' are 'not what you expect it to do' according to documentation. Turning this to Auto or On will not always generate the assemblies you need.

After you've run this tool you now have a library that contains all serializers for you project. You can now use this library to check whether the expected serializers are available.

Hope this helps,

Marvin Smit
+2  A: 

The simplest way to test these type of problems (where serialization is incomplete or incorrect) is to unit test - nothing complicated.

  • Create an object of your serializable type
  • Set all of the properties
  • Serialize it
  • Take the serialized output and deserialize it into a new object
  • Check all of the properties of the object to make sure they're still populated
  • Fail the unit test if any of the properties aren't set to the expected value

Remember that it's usually the behaviour you're trying to prove - not the implementation. Tools that check for specific attributes are only of value for testing a single implementation of your code: a unit test like the above could work for any form of serialization or storage without rewriting the test.

Dan Puzey