3

I just noticed something particular. I have an internal stock service which is published through basicHttpBinding, and a customBinding (http+binary) for which metadata is enabled. I also included a mex endpoint for http. We use Visual Studio 2008 & VB.NET

Just recently we noticed that we were unable to succesfully add a service reference to this service in our other projects. All that it would generate was the first custom exception we included through a FaultContract (actually, there was only 1 type). if I'd add a simple web reference it would work correctly as well. Also, the WcfClient.exe had no problems either in loading the services. Just VS.NET add service reference wouldn't work.

In the service this exception inherits from Exception and is marked as serializable. That's all you're supposed to do, no?

Anyway, this had me baffled. If I remove the FaultContract for this custom exception everything works fine. I can add a service reference, no problem. But is there a way I can still have my custom exceptions? Is this a known problem?

John Saunders
  • 160,644
  • 26
  • 247
  • 397
SpoBo
  • 2,100
  • 2
  • 20
  • 28
  • You _do_ realize of course, that the Exception will be meaningless to any platform other than .NET? – John Saunders Feb 08 '11 at 02:26
  • No but my impression of it was that the inheretance from Exception was needed for the WCF framework. It's also something that I assumed was right because it was always able to create the correct proxy class for the custom exception that inherited from Exception. – SpoBo Feb 15 '11 at 10:51

4 Answers4

8

I ran into this myself today. The solution was to use an object not inheriting from Exception in the FaultContract. If you look at the MSDN docs for FaultException and FaultContract you will see that the official examples use plain classes (with DataContact attributes) rather than classes extending Exception for FaultException.Detail. I'm not sure why Exception causes the Add Service Reference to fail, but I suspect it has to do with the serializing or retrieving the type information for custom exceptions. I have included before and after example implementations to demonstrate the working approach.

Before (didn't work):

[ServiceContract]
public interface IMyService
{
    [OperationContract]
    [FaultContract(typeof(MyException))]
    MyResults MyServiceOperation(string myParameter);
}

[Serializable]
public class MyException : Exception
{
    public string CustomData { get; set; }
}

[ErrorHandlerBehavior(typeof(MyErrorHandler))]
public class MyService : IMyService
{
    public MyResults MyServiceOperation(string myParameter)
    {
        ...
        throw new MyModelException { CustomData = "42" };
        ...
    }
}

public class MyErrorHandler : IErrorHandler
{
    public bool HandleError(Exception error) { return false; }

    public void ProvideFault(Exception error, MessageVersion version, ref Message fault)
    {
        try { throw error; }
        catch (MyModelException ex)
        {
            var faultEx = new FaultException<MyException>(new MyException { CustomData = ex.CustomData });
            fault = Message.CreateMessage(version, faultEx.CreateMessageFault(), faultEx.Action);
        }
        catch { /* Supress all others */ }
    }
}

After (worked):

[ServiceContract]
public interface IMyService
{
    [OperationContract]
    [FaultContract(typeof(MyFault))]
    MyResults MyServiceOperation(string myParameter);
}

[DataContract]
public class MyFault
{
    [DataMember]
    public string CustomData { get; set; }
}

[ErrorHandlerBehavior(typeof(MyErrorHandler))]
public class MyService : IMyService
{
    public MyResults MyServiceOperation(string myParameter)
    {
        ...
        throw new MyModelException { CustomData = "42" };
        ...
    }
}

public class MyErrorHandler : IErrorHandler
{
    public bool HandleError(Exception error) { return false; }

    public void ProvideFault(Exception error, MessageVersion version, ref Message fault)
    {
        try { throw error; }
        catch (MyModelException ex)
        {
            var faultEx = new FaultException<MyFault>(new MyFault { CustomData = ex.CustomData });
            fault = Message.CreateMessage(version, faultEx.CreateMessageFault(), faultEx.Action);
        }
        catch { /* Supress all others */ }
    }
}

Source: Max Strini for the use of his code and help in finding the solution to this issue.

Community
  • 1
  • 1
Joseph Sturtevant
  • 13,194
  • 12
  • 76
  • 90
  • thx :) i always assumed that WCF needed an object with something that is or inherits from exception in order to create a proper FaultException. – SpoBo Feb 15 '11 at 10:50
  • This worked great. I had to generate a service from a WSDL using svcutil and I couldn't figure out what to do with the exceptions. This answer solved my problem, thanks for that! – Zoidberg May 22 '12 at 15:15
1

I found the following article on how to create a fault contract using objected inherited from System.Exception: http://blog.clauskonrad.net/2008/06/wcf-and-custom-exceptions.html

However, it didn't work for me. I suspect the reason it didn't work for me is that I'm using a BasicHttp binding and not a .NET-.NET binding.

Timothy Klenke
  • 814
  • 1
  • 10
  • 21
  • The following from the article was key for me: "Provide a protected constructor allowing for the serialization process taking SerializationInfo and StreamingContext as arguments". One I provided that constructor on my custom exception, I could keep the System.Exception` inheritance. – Jeff B Nov 26 '14 at 21:46
0

I've also hit this issue. I ended up using the svcutil.exe to generate the proxy which doesn't appear to suffer the same issue.

Nick Wright
  • 1,403
  • 13
  • 19
  • The one true fix is to not use Exception class derived models (or probably any .NET Core class model) as a DataMember. Just restrict yourself to POCO's and your WCF contract will be correct, cleaner and more compatible with other technologies. (Java, PHP, etc) – SpoBo Sep 12 '11 at 09:53
0

I had the same problem and solved it by generating the proxy using SVCUTIL.exe. I had the custom fault setup exactly the way MSDN recommends but "add service reference" was not including the fault contract in the proxy. Then I used the SVCUTIL and it worked like magic :)

MuazzamAli
  • 201
  • 2
  • 11
  • 1
    It's best to resolve the issue so you can just generate the code inside visual studio. WHo knows what other tools show the same behavior. + each time somebody tries to add your service it'll become a problem. I would start excluding files one by one, recompile and try adding the service reference again. This is only applicable if you are writing the service yourself. – SpoBo Jan 27 '12 at 15:05