I have already developed my application, which has more than a 1000 functions. Now I need to implement fault contracts or exception handling in Silverlight without changing these functions.
Is there any common method that I can implement in one place in the WCF service layer and in one place in the Silverlight Application?
I want to implement this because when any exception occurs in the WCF layer, it will not send the real exception message to silverlight.
Silverlight only gets a message like this:
"Remote server not found..."
Real problem is i have already developed the system and now i need to implement the falultcontracts without changing too much or each function in Service layer.. so is there any method to create the falutcontract wrapper and place it over the WCF service Layer?
It's not 100% clear to me from the question what's going on in your case, but I can mention:
If you get an exception in Silverlight that the "Remote server not found..." then you won't get any exception details no matter what you do in the service (how can the service respond with those details, if the Silverlight app can not find the service?).
If you want to see exception details from the service in your app for debugging purposes, you can apply it to the entire service through the IncludeExceptionDetailInFaults property in the ServiceBehavior. This is considered a security risk (disclosing internal exception details) so it's not recommended for production.
As far as I know FaultContracts have to be set on the operations themselves, and you have to be explicit when you throw them.
PS. Your real problem may be that you have over a 1000 functions in your service, that doesn't seem healthy. On the other hand, if they are generated functions it may turn out to be a mixed blessing as you may be able to generate some fault code as well?
Related
Strangely I can't find anything on google for this. When doing regular exception stuff you'd create a MyCustomException : Exception and I assumed the same applied to ExceptionFaults.
When someone calls my service with an invalid api key, I wanted to throw an InvalidApiKeyExceptionFault. I can't seem to find an example online of how to set this up and have the client be able to catch it (presumably an attribute somewhere to include it into the WSDL).
Any suggestions where to look, or am I trying something that's not possible?
You should use FaultException<TDetail> and put your specific information in the serializable TDetail type.
Your service contract should have a fault contract specifying the TDetail type.
This technique enables you to communicate error information in an interoperable way, including to clients that know nothing about .NET exceptions.
If for some reason you don't want to use fault contracts, you could consider using the non-generic FaultException, and communicate additional information about the error in the fault reason and/or fault code / subcode.
I keep getting the 400 bad request if there is de-serialization issue / other errors. If i try to debug by setting a breakpoint in the method that gets called, it does not get hit, if there is a deserialization issue. How do I intercept this and tweak the response to give me more details.
I looked at some articles regarding webprotocolexception but I think the WCF Rest online Template and the starter kit or not the same. Is the starter kit like an add-on to the template?
thanks for your time.
Handling Exceptions in RESTful WCF Services is tough. Deserialization issues are the worst since no user code gets called. The framework handles the Exception and simply returns an error to the caller. There is a way to see those errors though. You have to configure tracing for WCF (via Web.config). Here’s a link describing the process as well as where to find the trace viewer on your machine:
Service Trace Viewer Tool (SvcTraceViewer.exe)
Unfortunately there's no way to tweak that behavior. For other Exceptions, though, you can implement a custom HttpBehavior (or HttpBehavior2 if you're using the REST Starter Kit) with a custom IErrorHandler implementation to handle the Exceptions.
Error 400 means bad request => it is picked up at WCF level and does not even reach the method. So you need to look at the request and if you are passing JSON, fast chance it is in wrong format.
I had a personal project that I implemented in WCF REST and had to battle with this error which was quite frustrating. Also error handling on the server and returning error codes to the client is atrocious since you cannot return text content and all I have is HTTP error code and error description (first line in the HTTP response). I will never ever use WCF REST again as it is a bodged implementation.
I want to log all exceptions (including serialization exception stack traces) in a WCF server to the Windows Event Log (log4net logging would also be acceptable).
What is the easiest way to do this?
Specifically all errors in serialization, in the service itself, etc. Right now I'm using tracing to get serialization errors during development. Tracing was the only way I could find out what object was actually have a problem with serialization. See Quickly finding WCF Serialization/Deserialization Issues for an example of getting the serialization stack trace.
I can handle errors in the service code itself. However, errors in the WCF machinery don't propagate to my service code (like serialization errors).
I don't need to send the errors to the client.
I just want to get the errors into one location (like the Event Log).
Right now (from my research) it appears that the IErrorHandler Interface with some custom code might be the best way to proceed. Will using the IErrorHandling interace catch the serialization exceptions?
Edit:
This may be the answer I'm looking for:
How do I create a global exception handler for a WCF Services?
I'd just like a confirmation that this will catch serialization errors and more importantly the details of those errors, also.
More Info:
How do I create a global exception handler for a WCF Services?
Yes, IErrorHandler will also catch serialization exceptions. You will get all information stored in the exception. Whether or not this enough detail for you, I can't say.
Note that there may be client-side errors (serialization and others) which will never make it to the server. You will not see those with the IErrorHandler.
At first I treated them as any dependency passing them in the ctor to the class consuming the service:
var serviceConsumer = new ServiceConsumer(new MailingServiceClient())
The problem was that once an exception was thrown from the service it entered a faulted state and would not reply to any requests, so re-initialization was due.
Further more, I became familiar with the fact that wcf services may not be disposed properly on several occasions, because the dispose method of the generated proxy is broken (calls close without checking the fault state) and encountered a couple of ways to overcome that:
wrapping every call to every service.
override the default IDisposable behavior of the scvutil.exe-generated class
Since I wouldn't like the consumer code to create the service client himself for testing reasons, my questions are:
how can I maintain a working un-faulted service?
how can I still use dependency injection for testability?
Found a nice solution.
a proxy generator that replaces the VS one, and generates a wrapper around the default proxy that deals with proxy faults, timeouts, and correct disposal.
http://wcfproxygenerator.codeplex.com/
seems to be working fine for me.
I've got some WCF services (hosted in IIS 6) which use the Enterprise Library (4.0) Validation Application Block. If a client submits a message which fails validation (i.e. gets thrown back in a ValidationFault exception), I'd quite like to be able to log the message XML somewhere (using code, no IIS logs). All the validation happens before the service implementation code kicks in.
I'm sure it's possible to set up some class to get run before the service implementation (presumably this is how the Validation Application Block works), but I can't remember how, or work out exactly what to search for.
Is it possible to create a class and associated configuration that will give me access to either the whole SOAP request message, or at least the message body?
Take a look at using the Policy Injection Application Block...
I'm currently developing an application in which I intercept (using PIAB) all requests incoming to the server and based on the type of request I apply different validation behavior using the VAB.
Here's an article about integrating PIAB with WCF:
http://msdn.microsoft.com/en-us/magazine/cc136759.aspx
You can create different inteception mechanisms such as attributes applied to exposed operations.
You could log the whole WCF Message:
http://msdn.microsoft.com/en-us/library/ms730064.aspx
Or you could combine it with Enterprise Library Logging Application Block.
I found a blog post which seems to do what I want - you create a class that implements IDispatchMessageInspector. In the AfterReceiveRequest method, you have access to the whole incoming message, so can log away. This occurs after authentication, so you also have access to the user name - handy for logging. You can create supporting classes that let you assign this behaviour to services via attributes and/or configuration.
IDispatchMessageInspector also gives you a BeforeSendReply method, so you could log (or alter) your response message.
Now when customers attempt to literally hand-craft SOAP request messages (not even using some kind of DOM object) to our services, we have easy-to-access proof that they are sending rubbish!