XmlSerializer：将类属性序列化为自定义子元素的属性

Question

I'm using an XmlSerializer . My class:

[Serializable]
[XmlRoot(ElementName="MyClass")]
public class MyClass
{
    public string Value;
}

I would like to serialize it so that Value ends up as an attribute of a subelement named (for instance) "Text".

Desired outcome:

<MyClass>
    <Text Value="3"/>
</MyClass>

But NOT (which would be the effect of marking Value as an XmlAttribute )

<MyClass Value="3">
</MyClass>

And NOT (which would be the effect of marking Value as an XmlElement ):

<MyClass>
    <Value>3</Value>
</MyClass>

How do I achieve this?

I am aware that I could change the type of Value from string to another serializable custom class.

Unfortunately, I have plenty of such properties, so I'd need to create dozens of tiny classes.

Is there any quicker solution?

---

EDIT:

In response to your comments:

• No, not every property has to be serialized to a subelement named "Text". Subelement's name is unique and unambiguous.

• Sample output XML:

   <visibility> <site visible="yes"/> <comparator visible="no"/> <expiration days="7"/> <comment>blahblahblah</comment> <visibility> 

• Sample class:

!

[XmlRoot(ElementName="Visibility")]
public class Visibility
{
    [XPath("/site@visible")] // if only this was possible!
    public string OnSite
    {
        get { return SiteVisible ? "yes" : "no"; }
    }

    [XPath("/comparator@visible")] // as above...
    public string InComparator
    {
        get { return ComparatorVisible ? "yes" : "no"; }
    }

    [XmlIgnore]
    public bool SiteVisible;
    [XmlIgnore]
    public bool ComparatorVisible;

    [XPath("/expiration@days")] // as above...
    public int ExpiresAfterDays; 

    [XmlElement("comment")] // this is easy
    public string Comment;
}

Answer 1

Without changing the type of Value I think it's not possible. You can add the attribute XmlElement(ElementName="Text") on Value but you will obtain a result similar to this:

<MyClass> 
    <Text>3</Text> 
</MyClass> 

Edited: Another solution can involve XSLT transformation: you can generate the xml using .Net serialization and after apply a xml transformation.

XslTransform myXslTransform = new XslTransform();
myXslTransform.Load(xsltDoc);
myXslTransform.Transform(sourceDoc, resultDoc);

The trasformation of my example should be something like this:

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
    <xsl:template match="/">
    <root>
        <xsl:apply-templates/>
    </root>
    </xsl:template>
    <xsl:template match="MyClass">
        <MyClass>
            <Text>
               <xsl:attribute name="Value">
                    <xsl:value-of select="Text"/>
               </xsl:attribute>
            </Text>
        </MyClass>
    </xsl:template>
</xsl:stylesheet>

Answer 2

For this sort of flexibility, you should really think about implementing IXmlSerializable as this gives you much more control:

[XmlRoot("visibility")]
public class Visibility : IXmlSerializable
{
    public string Site;
    public string Comparator;
    public int Expiration;
    public string Comment;

    public XmlSchema GetSchema()
    {
        throw new NotImplementedException();
    }

    public void ReadXml(XmlReader reader)
    {
        // implement me if you want to deserialize too.
        throw new NotImplementedException();
    }

    public void WriteXml(XmlWriter writer)
    {
        WriteProperty(writer, "site", "visible", Site);
        WriteProperty(writer, "comparator ", "visible", Comparator);
        WriteProperty(writer, "expiration ", "days", Expiration);

        if (!string.IsNullOrEmpty(Comment))
        {
            writer.WriteElementString("comment", Comment);
        }
    }

    private void WriteProperty<T>(XmlWriter writer, string elementName, string attibuteName, T value)
    {
        if (value != null)
        {
            writer.WriteStartElement(elementName);
            writer.WriteAttributeString(attibuteName, value.ToString());
            writer.WriteEndElement();
        }
    }
}

Obviously, there is bit of manual work here, but it does allow you to keep all the serialization code in one place, rather than having a proliferation of smaller classes.

The example above only implements serialization - you'd need to write an equivalent deserialize implementation if you need to deserialize from xml to your type.

Answer 3

Thanks for all the answers. It's a pity that .NET XmlSerialization library does not allow for that (I think it should!). I'm looking for a solution as generic as possible.

The best one I could come up with (best one considering the criteria of maximum genericity, while being reasonably quick to implement) is letting the XmlSerializer serialize my class the way it likes, then just convert the output, relocating certain elements into nested locations.

Something like that:

    /// <remarks>
    /// (angle brackets replaced with round ones to avoid confusing the XML-based documentation comments format)
    /// 
    /// Let input XML be:
    /// 
    ///     (root)
    ///         (days)3(/days)
    ///     (/root)
    ///     
    /// Calling Reposition on this input with mappings argument being:
    ///     (key) "days"
    ///     (value) { "time", "days" }
    ///     
    /// Returns:
    /// (root)
    ///     (time days="3" /)
    /// (/root)
    /// </remarks>        
    static XElement Reposition(XElement input, KeyValuePair<string, string[]>[] mappings)
    {
        var result = new XElement(input);
        foreach (var mapping in mappings)
        {
            var element = result.Element(mapping.Key);
            if (element == null)
            {
                continue;
            }
            var value = element.Value;
            element.Remove();

            var insertAt = result;
            foreach (var breadcrumb in mapping.Value)
            {
                if (breadcrumb == mapping.Value.Last())
                {
                    insertAt.Add(new XAttribute(breadcrumb, value));
                }
                else
                {
                    insertAt.Add(new XElement(breadcrumb));
                    insertAt = insertAt.Element(breadcrumb);
                }
            }
        }
        return result;
    }

I think I would combine it with a custom attribute (kind of similar to the XPath attribute that I wished would exist: see the sample code in my question), and enwrap this functionality in a serializer class of my own.

Any comments / insights on this approach?

I can think of a potential performance drawback (rewriting/reparsing the XML after each serialization), but the resulting pieces of XML aren't expected to be of large size, so this is probably negligible.

The question of deserialization does not bother me at this point (deserialization has already been implemented and is done quite "manually", by XPath and some utility methods).