When throwing a FaultException from a WCF service, is there a way it can be thrown without faulting the actual connection? I'm looking to prevent an action for a particular method, but don't want to disrupt the client's connection (just return saying "you can't do this action right now, and here's why"). Or, is the required paradigm to recreate a new proxy in the .NET consuming app (in the case of .NET)
If you throw a FaultException then the client will get an exception but should be able to carry on using the same connection. If you let any other kind of exception out of the service (without having a Custom Error Handler in place) then it will fault the channel
Are you using .NET 4.0, can you use WebFaultException to return an HTTP status code with the appropriate error reason?
Related
I have a client connecting to third part WCF Service (I have access to the web.config or service but not code).
The Third Party throws a SOAP Exception because the faulting assembly isn't marked as serializable - "Type Assembly not marked as serializable".
Is there anyway I can get the underlying exception detail that was thrown and not faulted on the WCF Service via configuration edit or other means?
You need to enable includeExceptionDetailInFaults in your web.config file.
Please check this.
Background:
I've noticed that in my WCF services, when I throw an Exception (a plain old exception), the client channel enters the faulted state and has to be aborted and re-created before I can make another call on that channel. That's fine. That's how it's intended. I get it. So I just call abort() and re-create if I need to make another call.
However, faulting of the client channel only happens when I'm using a binding that has security enabled. When I use basicHttpBinding, I can get an exception on the client, and then keep using the ServiceClient object without it telling me it's in "the faulted state".
Also, when I turn off security on wsHttpBinding or netTcpBinding, I can re-use the channel after an Exception.
Question:
What is is about a binding's security that makes it fault the channel so it's unusable?
This is because with Security, you are setting up a secure session. When you throw out of that session, the channel enters the faulted state and you have to abort it and create a new one. With BasicHttpBinding, there's no session going on.
I have created a wcf service with NetMsmq binding. And the operations are one way.
I wanted to handle the fault exception. However i found that the channel is not going to fault even after the exception is raised at the server side.
Can anybody tell me in what cases the wcf service will goes to fault state(provided while using NetMsmqBinding).
I created a WCF service for logging using the enterprise library logging block. The service is working properly from an ASP.net website. Also the method is taking lists and primitive types as parameters so there should be no cross platform issues. So I place a reference of this service from visual studio into my silverlight project, which is mvvm by the way, and I make a call to the service. And nothing happens. No exception no logging nothing. At first I thought it was just an exception that was not propagating back to my service, so I placed a message immediately after my method's async call and that message ran fine. So I'm stumped. I also have a try catch block wrapping my service call and the catch block is never being called meaning an exception is not thrown.
This was my error I was getting an exception before the call and that was preventing my service from being hit.
I am working on a prototype using WCF 4 routing services to create a pass through router, leveraging the error handling functionality
I have a requirement where if a WCF service generates a custom exception (in this scenario it is called a notPrimaryException), it should be handled in the same way as a communication exception is handled in WCF4 routing services error handling, that is, the message should be resent to the endpoints in the backup list.
Now I understand that this custom exception is returned from the service to the router as a fault exception at the message layer as opposed to a communication exception being returned at the transport layer.
I have tried using message inspectors and the IErrorHandler interface (ProvideFault and Handle Error) to identify if the notPrimaryException is occurring at the router but nothing is being picked up until it returns to the client as an unhandled fault exception. I was hoping to intercept this fault somewhere on the router and resend the message accordingly but I don't know if there are any appropriate behaviors.
Is there a way to shoehorn additional exception/fault types into the error handling infrastructure or is there another approach I may have overlooked?
Thanks and Regards,
Ivan
You should not be handling application errors on the router. Generally, the application developer has placed FaultExceptions on the service with the expectation of being able to handle them on the client.
If the FaultException is not received by the client, how does the client know what/anything went wrong?
The only errors you should be handling on the router are transport layer exceptions, application exceptions should be handled in the application.