SOAP Request not Linearized

[Murdock92]

Hi,

I'm in the process of migrating an existing SOAP service to .NET. We deserialize to out classes using IXmlSerializable, reading the XML with an XmlReader.
In the old implementation using our SOAP service hosted on IIS, the entire message enters our code already linearized, containing no new lines or whitespace between tags.
In CoreWcf, the message enters our code in the original shape sent (from SoapUI in this case), meaning our code to read the elements fails because it reads a newline and fails a comparison to what we think it should be (in this case an element).
Is this configurable behaviour I can change in CoreWcf?

[mconnew]

Is it possible for you to try running your service using CoreWCF on .NET Framework?

My initial thought is that this is a difference in the .NET runtime from .NET Framework as I can't think of anything we changed in CoreWCF which would cause this. If you are able to run your service on .NET Framework, this would be easy to validate.

Can you use a debugger to check what the implementation type is of the XmlReader that's passed to your IXmlSerializable type? I know we made a change to XmlSerializer to use a different XmlReader/Writer type by default (one which is more standards compliant and doesn't accept invalid XML), but WCF/CoreWCF shouldn't have been affected as we provide our own XmlReader/Writer types.

Are you able to provide the XML snippet that's being deserialized as it appears on the wire. If SoapUI doesn't provide this, you could use Fiddler Classic to capture it.

The problem you are having is ultimately down to small bugs in your code where you aren't reading from the XmlReader using the correct pattern as XmlSerializer/DataContractSerializer and CoreWCF/WCF Client are still able to read the incoming XML even though it's presented differently. Don't get me wrong, I'm not victim blaming here, you should have an expectation that your existing code should work the same, even if it's not using the expected patterns. The reason why I bring this up is from the pragmatic point of view of looking for a solution. Once we know what's causing it, there might be a service behavior you could add which changes how the XML is parsed and you have a solution. If that's not possible, and if a fix is possible in .NET (there's a high bar for behavior change which might be breaking as others might have already adjusted their code), you might have to wait until .NET9 to get a fix. Or it might not get fixed. What's your tolerance level for making a change in your own code?

I see a few possible ways to address it in your code. Change the usage pattern, which is likely to be lots of touch points in your code. This may or may not be painful as it might be doable with a simple regex to insert an extra call before another call, or change a method call to a different one. A more costly at runtime approach might be to round trip it through XmlDocument to get an XmlReader which presents the Xml how you want. That could be 3 lines of code you insert at the top of every ReadXml method. Or it could be write an XmlReader wrapper which wraps the passed XmlReader which consumes the extra line. This is more code to write and own, but less runtime overhead, and less touch points in your code. Knowing what you can tolerate and your priorities can help find the best solution for you.

But first we need to work out if it's a runtime issue, or CoreWCF, then work out the root cause, then see if there's an easy workaround to change behavior, and modifying your implementation of ReadXml would be the last resort.