This blog is in continuation of my other blog. In the first blog, I explained how to use XML attribute overrides to reduce the number of attributes required in source code, and how to centralize some common functionality in a single location (the blog focused on how to serialize to XML using camel casing as default for tag names). I will be referring to code from that first blog, so I do recommend you to read that one first.
That said, let’s get into that topic: REST Services many times return a collection, a list of objects. When the format is JSON, the returned text will look something like the following.
- [ { prop1 = “x”, prop2 = “y’} , { prop1 = “a”, prop2 = “b”}, …..]
When the response is XML, the code might look like this.
- <allCustomers>
- <myCustomer>
- <prop1>x</prop1>
- <prop2>y</prop2>
- </myCustomer>
- <myCustomer>
- etc
- </myCustomer>
- </allCustomers>
In order to deserialize this content, people see the need to create a helping class, like this one.
- [XmlRoot(ElementName = "allCustomer")]
- public class ListOfCustomers : List<MyCustomer>
- {
- }
So, a real project ends up having many classes like this one: Empty, and repetitive. Well, when something is repetitive, there must be a better way. And when something is empty.... yikes! Awful!
Here is the tricky part: Marking class MyCustomer with an XmlRoot attribute won’t do the trick. The root is of type List<MyCustomer>, so an XmlRoot attribute tied to MyCustomer does nothing.
There is another problem to solve - Whether “MyCustomer” has an XmlRoot attribute or not. There has to be a way to tell the deserializer the tag name to use when finding a list. It could be programmed in the attribute override code to be setting all such tags to be something like listOfxxxxx where xxxxx is the name of the generic element. But this solution would be restrictive. This will definitely not help in many real life scenarios. Another way is to create a new attribute
- [XmlObjectWrapper(ElementName = "allCustomers")]
This attribute will be used when processing the overrides. It will tell the code that generates the overrides: “Hey, if you ever need to deserialize a list, or array of these type of object, the surrounding tag name should be allCustomers”. So you do need to add this new attribute to the classes which you know will become members of a list to be deserialized.
The definition of the new attribute is quite simple:
- namespace MyProject
- {
- using System;
- public class XmlObjectWrapperAttribute : Attribute
- {
- public string ElementName { get; set; }
- }
- }
Here is the definition of class MyCustomer now including this attribute:
- [XmlObjectWrapper(ElementName = "allCustomers")]
- public class MyCustomer
- {
- public string NameAndLastName { get; set; }
- public int Age { get; set; }
- public Double Height { get; set; }
- public Gender Gender { get; set; }
- public List<Book> ReadingPile { get; set; }
- public Boolean Active { get; set; }
- [XmlElement(ElementName = "WEEKLY_MONEY")]
- public Decimal Allowance { get; set; }
- public MyCustomer ReferredBy { get; set; }
- }
Here, I repeat the “CreateAttributeOverrides” method, which I published in my previous blog. This one is the improved version which handles deserialization of objects into Lists of something. I have highlighted the relevant code.

Join the conversation! Your thoughts help the community grow.