Force a Service to use XmlSerializer instead of DataContractSerializer

I have to support a specific client’s DTO that is XML and requires the use of attributes. I figured out how to default that service to XML via the AddHeader attribute on the Service. However, it seems that deserialization for the response is using DataContractSerializer. How can I force only that Service to use XMLSerializer instead of DataContractSerializer?

ServiceStack uses DataContractSerializer for XML Serialization, in this previous answer I provide different ways on how you can use a different Xml Serializer instead.

If you just need to serialize XML in one service you can just serialize it in your Service and return an xml string, e.g:

return XmlSerializer.SerializeToString(response);

Thanks @mythz. I’ll check that out.

On a similar note, the response going back to the client has to be in url-encoded form format such as…

xmlresponse=%3C%3Fxml+version%3D%221.0%22+encoding%3D%22UTF-8%22%3F%3E%0A...

However, I get a 405 Method Not Allowed when I try to do a…

return new HttpResult(new { xmlresponse = result.ToXml() }, MimeTypes.FormUrlEncoded);

I also get a 405 if I url-encode the result first and do a…

return new HttpResult(new { xmlresponse = urlEncodedResultString }, MimeTypes.FormUrlEncoded);

Thoughts?

return new HttpResult(new { xmlresponse = result.ToXml() }, MimeTypes.FormUrlEncoded);

This makes no sense, you want to return a raw XML string with an XML Content-Type. Here you’re returning a nested anon object with an XML String property that you’re saying has a Form UrlEncoded Content-Type when it’s not.

See the Customize HTTP Response docs on different ways to set the Response Content-Type, e.g:

[AddHeader(ContentType = MimeTypes.Xml)]
public object Any(Request request)
{
    ...
    return result.ToXml();
}

I was able to get the response going with…

return new HttpResult("xmlresponse=" + urlEncodedResultString, MimeTypes.FormUrlEncoded);

As long as that’s what you want on the wire, but you’re returning a url encoded xml string in a urlencoded FormData Content-Type which is inefficient, verbose and poorly introspectable/interoperable, but fine if that’s what your client expects.

Oh believe me, I understand how ridiculous it is. Ha! But that’s what they require going back to them.