Bug 42226 - WCF client Expecting FaultException<TDetail> raising NotImplemented Exception instead When <FaultActor> element is provided.
Summary: WCF client Expecting FaultException<TDetail> raising NotImplemented Exception...
Alias: None
Product: iOS
Classification: Xamarin
Component: BCL Class Libraries ()
Version: XI 9.6 (iOS 9.3)
Hardware: All All
: --- normal
Target Milestone: (C9)
Assignee: Alexander Köplinger [MSFT]
Depends on:
Reported: 2016-06-29 03:15 UTC by Rami
Modified: 2017-02-21 22:21 UTC (History)
9 users (show)

Is this bug a regression?: ---
Last known good build:

Definitive Test Solution That Shows the Problem (131.85 KB, application/x-zip-compressed)
2016-07-04 23:52 UTC, Rami

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Description Rami 2016-06-29 03:15:39 UTC
When using a WCF proxy client(derived using SlSvcUtil.exe) in a PCL, and referenced in Xamarin.IOS the following server response raises a "Not Implemented Exception":

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
         <faultstring>The creator of this fault did not specify a Reason.</faultstring>
            <ns:ECFPFault xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:ns="http://RamiCorpSolutions/BusinessObjects" xmlns:ns0="http://schemas.xmlsoap.org/soap/envelope/">
               <ns:ErrorMsg>Unknown LoginName</ns:ErrorMsg>

However, when the server responds with the following Messagae, the expected Faultexception<TDetail> is raised.

<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
         <faultstring xml:lang="en-US">The creator of this fault did not specify a Reason.</faultstring>
            <ECFPFault xmlns="http://RamiCorpSolutions/BusinessObjects" xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
               <ErrorMsg>Unknown LoginName</ErrorMsg>

The only difference in the responses(other than general namespacing semantics) is the inclusion of the "FaultActor" element. 

I have referenced the PCL in a Console application and BOTH responses were handled correctly which leads me to conclusively assume the issue is in Mono's implementation of the WCF stack.

Below is the Stack Trace:
StackTrace " at (wrapper managed-to-native) System.Object:__icall_wrapper_mono_delegate_end_invoke (object,intptr)\n at (wrapper delegate-end-invoke) :end_invoke_object__this___object[]&_IAsyncResult (object[]&,System.IAsyncResult)\n at System.ServiceModel.MonoInternal.ClientRuntimeChannel.EndProcess (System.Reflection.MethodBase method, System.String operationName, System.Object[] parameters, IAsyncResult result) [0x00025] in /Users/builder/data/lanes/3412/3cf8aaed/source/maccore/_build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/src/mono/mcs/class/System.ServiceModel/System.ServiceModel/ClientRuntimeChannel.cs:460 \n at System.ServiceModel.ClientBase1+ChannelBase1[TChannel,T].EndInvoke (System.String methodName, System.Object[] args, IAsyncResult result) [0x0003c] in /Users/builder/data/lanes/3412/3cf8aaed/source/maccore/_build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/src/mono/mcs/class/System.ServiceModel/System.ServiceModel/ClientBase.cs:404 \n at ECFPLib.ECFPService.ECFPServiceClient+ECFPServiceClientChannel.EndLogin (IAsyncResult result) [0x00010] in /Users/ramiayyad/Documents/RDC Connections/Bonobo.Git.Server/ECFP.git/ECFPLib/Service References/ECFPService/Reference.cs:2778 \n at ECFPLib.ECFPService.ECFPServiceClient.ECFPLib.ECFPService.IECFPService.EndLogin (IAsyncResult result) [0x00008] in /Users/ramiayyad/Documents/RDC Connections/Bonobo.Git.Server/ECFP.git/ECFPLib/Service References/ECFPService/Reference.cs:1939 \n at ECFPLib.ECFPService.ECFPServiceClient.OnEndLogin (IAsyncResult result) [0x00003] in /Users/ramiayyad/Documents/RDC Connections/Bonobo.Git.Server/ECFP.git/ECFPLib/Service References/ECFPService/Reference.cs:1949 \n at System.ServiceModel.ClientBase`1+c__AnonStorey0[TChannel].<>m__0 (IAsyncResult ar) [0x00006] in /Users/builder/data/lanes/3412/3cf8aaed/source/maccore/_build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/src/mono/mcs/class/System.ServiceModel/System.ServiceModel/ClientBase.cs:242 " string

The FaultContract was defined as follows:

    [DataContract(Namespace = "http://RamiCorpSolutions/BusinessObjects")]
    public class ECFPFault

        public ErrorCode ErrorCode { get; set; }

        public string ErrorMsg { get; set; }


With a sample interface defined as:
        [FaultContract(typeof(ECFPFault), Namespace = "http://RamiCorpSolutions/BusinessObjects")]
        String Login(string Username, string Password);

Final note,
If you're wondering how the service was implemented, we took the WSDL generated by WCF and implemented in another platform(WSDL first approach).
Comment 1 Alex Soto [MSFT] 2016-06-30 13:34:31 UTC
Please include a small test case so we can reproduce the issue also
all version informations of yours.

The easiest way to get exact version information is to use the 
"Xamarin Studio" menu, "About Xamarin Studio" item, "Show Details" 
button and copy/paste the version informations (you can use the 
"Copy Information" button).
Comment 2 Rami 2016-07-04 23:43:46 UTC
Xamarin Studio Community
Version 6.0.1 (build 9)
Installation UUID: e25951a0-f9cb-4eec-a141-04474014d095
	Mono 4.4.1 (mono-4.4.0-branch-c7sr0/4747417) (64-bit)
	GTK+ 2.24.23 (Raleigh theme)

	Package version: 404010000

Not Installed

Apple Developer Tools
Xcode 7.3.1 (10188.1)
Build 7D1014

Version: (Xamarin Studio Community)
Hash: 3cf8aae
Branch: c7sr0
Build date: 2016-06-20 16:09:58-0400

Version: (Xamarin Studio Community)
Android SDK: /Users/ramiayyad/Library/Developer/Xamarin/android-sdk-macosx
	Supported Android versions:
		4.0.3 (API level 15)
		4.4   (API level 19)
		6.0   (API level 23)

SDK Tools Version: 24.4.1
SDK Platform Tools Version: 23.0.1
SDK Build Tools Version: 23.0.1

Java SDK: /usr
java version "1.7.0_71"
Java(TM) SE Runtime Environment (build 1.7.0_71-b14)
Java HotSpot(TM) 64-Bit Server VM (build 24.71-b01, mixed mode)

Android Designer EPL code available here:

Xamarin Android Player
Not Installed

Version: (Xamarin Studio Community)

Build Information
Release ID: 600010009
Git revision: e879ce52093257c5c386ad7e390dfaa937fa7f90
Build date: 2016-06-24 11:53:43-04
Xamarin addins: a9252e6df4851fbbed1f9c6228e7b6dd1b475ac5
Build lane: monodevelop-lion-cycle7-sr0

Operating System
Mac OS X 10.11.4
Darwin Ramis-MacBook-Air.local 15.4.0 Darwin Kernel Version 15.4.0
    Fri Feb 26 22:08:05 PST 2016
    root:xnu-3248.40.184~3/RELEASE_X86_64 x86_64
Comment 3 Rami 2016-07-04 23:52:23 UTC
Created attachment 16566 [details]
Definitive Test Solution That Shows the Problem

The attached solution definitively proves the issue is due to the Addition of the <FaultActor> element.

The sample solution provides a PCL with the WCF client along with a simple server that generates a 2 fault soap messages. The messages are identical except for one containing the <FaultActor> element.

When the PCL is referenced in an IOS project, The message which generates the Soap Fault with the <FaultActor> element raises a "Not Implemented Exception".

When the PCL is referenced in a Console Application(also included in the project), Both Soap Messages are handled.
Comment 4 Rami 2016-07-05 00:00:17 UTC
Am I allowed to set this to "Confirmed".
Comment 5 Rami 2016-07-05 05:17:23 UTC
As a work around, is there anyway to have the client modify the incoming message before parsing it? In regular WCF we would do this using IClientMessageInspector and implementing the AfterReceiveReply method. Unfortunately, I dont think we can do the same with Silverlight WCF. Or can we?
Comment 6 Rami 2016-07-05 15:01:56 UTC
Added information. Please let me know if more info is needed.
Comment 7 Rodrigo Kumpera 2016-07-05 16:56:33 UTC
Hey Marcos,

Could you take a look at this one?
Comment 8 Jigar 2016-08-02 13:01:06 UTC
Is this bug resolved ?
Comment 9 Rami 2016-08-10 19:52:54 UTC
I dont think it's resolved yet. I'm wrapping my faults in a regular output message now. Not Ideal. I wish there was a way my service would remove the faultactor element but it can't
Comment 10 Alexander Köplinger [MSFT] 2016-11-04 15:22:57 UTC
I opened a PR with a fix in https://github.com/mono/mono/pull/3894
Comment 11 Alexander Köplinger [MSFT] 2016-11-07 17:28:36 UTC
Merged to Mono master/213bce206b46a94c5a80aad2965a45f2aff675f5 and mono-4.8.0-branch/e6b9ba890809d7d24a5411085a6f76b63ffa58a5
Comment 12 asimk 2017-02-07 17:54:41 UTC
@Alex, I have checked this issue with latest master build and observed that I am still getting exception on EndFaultGeneratingMethod 
Here is the screencast for the same: https://www.screencast.com/t/rIfReePxat
Comment 13 Alexander Köplinger [MSFT] 2017-02-07 21:12:33 UTC
@asimk the exception you're getting says "There was no endpoint listening at ....". This is expected since I assume you don't have the service running on IP which the repro project uses.

Try changing to the IP of your machine.

Since you're not getting the NotImplemented exception that this bug was about, I'm setting this back to resolved/fixed.
Comment 14 GouriKumari 2017-02-21 22:21:39 UTC
I set the IP of fault generating server to the ip address of the machine that host the server. But when I click on No fault Actor or With fault Actor, I am getting a message that  "Did not catch custom fault". I am closing this issue since I am not getting any exception. 

## Test Env: