Question: XmlArrayItemAttribute support?

Hi there,

I have used the framework default XmlSerializer in the past but am running into problems when porting to .net core, so I’m currently trying to find out if ExtendedXmlSerializer can jump in.

I have made excessive use of the XmlArrayItemAttribute (for using it’s Type member to serialize DerivedTypes in generic lists). I have already found this to be dead easy using ExtendedXmlSerializer, but am worrying about how to deserialize existing xml from the default XmlSerializer.

public class SomeClassToSerialize
{
    [XmlElement(ElementName = "SomeProperty", Type=typeof(SerializationHelper<SomeAbstractClass>))]
    public SomeAbstractClass SomeProperty { get; set; }

    [XmlArray(ElementName = "SomeList")]
    [XmlArrayItem(ElementName = "SomeEntry", Type=typeof(SerializationHelper<SomeAbstractClass>))]
    public List<SomeAbstractClass> SomeList { get; set; } = new List<SomeAbstractClass>();
}

Is there a configuration for the “item name” in collections? Or an easy way to handle this in a custom serializer? This is an example xml:

<?xml version="1.0" encoding="utf-8"?>
<SomeClassToSerialize xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
    xmlns:xsd="http://www.w3.org/2001/XMLSchema">
    <SomeProperty type="ClassLibrary1.DerivedClass, ClassLibrary1">
        <DerivedClass>
            <SomeString>Dieser Satz kein Verb</SomeString>
        </DerivedClass>
    </SomeProperty>
    <SomeList>
        <SomeEntry type="ClassLibrary1.DerivedClass, ClassLibrary1">
            <DerivedClass>
                <SomeString>Ein Listeneintrag</SomeString>
            </DerivedClass>
        </SomeEntry>
        <SomeEntry type="ClassLibrary1.AnotherDerivedClass, ClassLibrary1">
            <AnotherDerivedClass>
                <SomeInt>12</SomeInt>
            </AnotherDerivedClass>
        </SomeEntry>
    </SomeList>
</SomeClassToSerialize>

[wexman]

Yes, that would be a possibility. I’m now kind of redesigning the whole thing so it would let us use all kinds of different serializers where we’re now just using System.Xml.XmlSerializer, for example there’ll be an ExtendedXmlSerializer, a NewtonsoftJsonSerializer, a ProtobufSerializer or whatever. Should have done this from the very beginning…

[wexman]

Hi Mike, thanks for getting back to me. While I don’t like the idea of XSLT transforming the data, it is an idea nevertheless! I’ve run into several other problems with the default XmlSerializer in the meantime regarding .net standard (things not working there which were working fine under .net framework but ms won’t fix it for obscure reasons), so it’s quite likely this’ll be the way to go. Be prepared for more questions incoming 😉