How to Get .NET XMLDeserializer To Deserialize to Types in a Specific .NET Namespace?

J

JamesHoux

Guest
I am working with a very old remote API to which I send XML requests and receive very similar XML responses. The requests and responses all have the same element names (of which there are literally thousands) that correspond to C# classes I am generating.

The docs for this API provide the full 10,000+ line XML schema for requests, as well as an even larger XML schema for responses. I am using Visual Studio .net tools to generate C# classes from the Xml schemas (XSDs).

Naturally, the result is two sets of C# Types with the same type names. I have to put the sets in two different namespaces to distinguish between them (MyAppXml.Request and MyAppXml.Response).

The problem is that when I need to deserialize XML, I don't know how to get the deserializer to construct CLR Objects using types from the correct namespace.

I've googled for answers with no luck. I found a Reddit post from a person with exactly the same problem, and it looks like he was never able to resolve it! https://www.reddit.com/r/csharp/comments/3g0f67
For the record, any suggestions that involve the Xml Namespace attribute element are not an option. The response XML objects do not specify a namespace. In fact all the xml header looks like is this:

<?xml version="1.0" encoding="ISO-8859-1"?>


Additional information: I know that when I create an XmlSerializer, I can specify the root level Type with new XmlSerializer(myType). The problem is that myType contains fields of that point to other types that exist in both .NET namespaces. A human might intuitively know to pick the same namespace as the root level type, but there's no way for the deserializer to actually know that's the correct intent.

Can I count on it trying to pick the same namespace first? I would think this would depend on implementation details of the deserializer, and it might even appear to work for a while and then break when a compile produces different ordering of types in the IL at some point in future projection.

Is there a way to resolve this so that I can guarantee the deserialization process will pick types from the correct namespace?

Continue reading...
 
Top