How to dynamically assign property names for XmlOnlyMediaFormatter

Hi @Darryl Hoar , and thanks for posting your question.

The XML element names should be treated as part of the public API contract. Changing a SQL column or an internal C# property should not automatically change the XML consumed by existing clients.

The simplest solution depends on which serializer XmlOnlyMediaFormatter uses.

If it uses XmlSerializer

Keep the new internal property name and explicitly preserve the old XML element name:

using System.Xml.Serialization;
public class CustomerDto
{
    [XmlElement("FirstName")]

    public string GivenName { get; set; }

    [XmlElement("LastName")]

    public string Surname { get; set; }
}

The application can use GivenName and Surname, while the response remains compatible:

<CustomerDto>
  <FirstName>John</FirstName>
  <LastName>Smith</LastName>
</CustomerDto>

XmlElementAttribute controls the XML element name when the object is serialized by XmlSerializer. (xmlelementattribute)

If this is ASP.NET Web API 2 and the formatter is not already using XmlSerializer, it can be enabled in WebApiConfig.Register:

public static void Register(HttpConfiguration config)
{
    config.Formatters.XmlFormatter.UseXmlSerializer = true;
    // Other Web API configuration...
}

Test this change first because switching serializers globally can also affect root elements, namespaces, collections, null handling, and other existing responses. ASP.NET Web API supports configuring the XML serializer for the formatter or for individual types. (json-and-xml-serialization)

If it uses DataContractSerializer

Use DataContract and DataMember(Name = ...) instead:

using System.Runtime.Serialization;
[DataContract]

public class CustomerDto
{
    [DataMember(Name = "FirstName")]
    public string GivenName { get; set; }
    [DataMember(Name = "LastName")]
    public string Surname { get; set; }
}

Do not combine both approaches until you confirm which serializer the custom formatter actually invokes.

Recommended long-term design

Avoid returning database entity classes directly. Introduce a dedicated response DTO whose names represent the stable external contract:

public class CustomerResponseV1
{
    public string FirstName { get; set; }
    public string LastName { get; set; }
}

Map the current database model to that DTO:

var response = new CustomerResponseV1
{
    FirstName = customer.GivenName,
    LastName = customer.Surname
};
return Ok(response);

This separates the layers:

Database model -> API DTO -> XML response

Future database changes can then be handled in the mapping without breaking clients.

Should the names be dynamic?

If “dynamic” means choosing different element names for different customers at runtime, attributes alone will not provide that behavior. Possible implementations include:

1. Separate DTOs or API versions for each supported contract.
2. A per-type XmlSerializer configured with XmlAttributeOverrides.
3. A custom MediaTypeFormatter.

ASP.NET Web API supports custom media formatters, but one should only be introduced when normal DTO mapping cannot represent the required contract. (media-formatters)

For this scenario, a custom formatter is probably unnecessary. Preserve the old XML contract using [XmlElement] or a dedicated legacy DTO, then version the endpoint if you want to expose the new names later. Also add an integration test that compares the generated XML structure against the legacy schema before deploying the change.

If this instruction is applicable to your situation, I would greatly appreciate it if you could follow the instruction here so others experiencing similar behavior can benefit from it as well.