WCF - FaultException with FaultCode causes CommunicationException on client

[dalefugier]

If a WCF server, running on Windows, throws a FaultException that contains a FaultCode to a WCF client, running on macOS, a CommunicationException is caught, not the expected FaultException.

Note, this is a regression an earlier version of Mono. I've tested against Version 4.0.2.

Steps to Reproduce

You can find source to a simple example that reproduces his behavior here:

https://github.com/dalefugier/Echo

Current Behavior

A FaultException that contains a FaultCode, thrown by a server, is caught as a CommunicationException on a client.

Expected Behavior

A FaultException that contains a FaultCode, thrown by a server, should be caught as a FaultException on a client.

On which platforms did you notice this

[X] macOS
[ ] Linux
[ ] Windows

Version Used:

Mono Version 5.16.0.220

Stacktrace

{System.ServiceModel.CommunicationException: Received an invalid SOAP Fault message ---
> System.Xml.XmlException: Content cannot be converted to the type
System.Xml.XmlQualifiedName. Line 1, position 78. ---> System.FormatException: The ':'
character, hexadecimal value 0x3A, cannot be included in a name.

[dalefugier]

If you'd rather not clone the repo, that contains the sample that replicates the issue, here is the solution:

Echo.zip

Thanks,

-- Dale

[EgorBo]

Duplicates #10304

[dalefugier]

@EgorBo , @marek-safar, I'm hoping I can get come clarification on why the issue was marked as Duplicate and Closed. The linked issue (10304) is related to Android, not macOS. And I'm using a fairly new, stable version of Mono. Is it possible to get someone to to test my Echo test harness with Xamarin.Mac 5.7 and confirm? If not, how can I get Xamarin.Mac 5.7?

Thanks,

-- Dale

[EgorBo]

@dalefugier the linked issue is cross-platform including Xamarin.Mac, see #10304 (comment)
I'll check your repro case just in case

[dalefugier]

@EgorBo, did you ever have a chance to look at the example I posted?

[dan-rigdon-bel]

@marek-safar When can we expect a fix for this bug to make its way into stable Mono? It looks like this and #10304 are fixed and in preview versions of Mono, but it would be helpful to know an approximate time period for graduating to stable. Thanks.

[marek-safar]

@dbelcher the fix should be available in stable Mono versions since Mono 5.20

[dan-rigdon-bel]

@marek-safar Thank you for the reply and the help interpreting this one. We are using the Visual Studio for Mac channel for our embedded Mono, so that explains it. Looking forward to seeing this one. Much appreciated.

[dalefugier]

@EgorBo, @marek-safar, we just tested the above code with Mono MDK 5.20.1.19, and the issue still exists. Can you re-open this issue?

[marek-safar]

@dalefugier are you saying it's not duplicate of the issue mentioned above or both of them are still failing with 5.20 ?

[dalefugier]

@marek-safar, we have no way of testing the linked issue, (10304), as it relates to Android and we don't develop for that platform. That said, we can still repeat the bug reported in this issue, (12995), with Mono MDK 5.20.1.19. I can only assume this issue is not a duplicate of the linked issue...

[dan-rigdon-bel]

Hi @marek-safar Is there any reasonable expectation that this could get fixed soon?
This remains an issue for us with Mono 6.4.0.198. The bug on our end that is a symptom of this bug:
https://mcneel.myjetbrains.com/youtrack/issue/RH-49443
remains a major annoyance for our users.

[marek-safar]

@steveisok please allocate some time to estimate fixes for this issue

[steveisok]

Appears our faultcode parsing was too 'by the book' as it tried to read the content as an XmlQualifiedName. This meant that <faultcode>s:1</faultcode> was being flagged as invalid because the xml spec says that the NameStartChar cannot be a number.

https://www.w3.org/TR/REC-xml/#NT-Name

I fixed this locally by taking the .net framework block that reads in the fault code. It's much more forgiving ;-). Only problem is I need to determine if I broke anything else.

[dan-rigdon-bel]

Thanks @steveisok! Great to see a fix was found. Can you help us understand which version of Mono this fix will go into? (Sorry, I'm not up-to-date with the release cycle tempo).