Silverilght client does not support FaultException. Only one 404 error is displayed. Therefore, the exception that is thrown by the service side cannot be passed directly through serialization/deserialization by the client. However, you can use some of the following methods to help you get an error message from the client:
1. At the Service end, the return value object is redesigned to add the error message to the field and pass it back.
2. When an exception occurs at the Service end, it is captured and the session store is used (while the log is available) and the result is return false.
In Silverlight the judgement returns false to invoke another service:getlasterror () to remove the exception information just saved from the session.
3. Modify the Service interface, add a ref parameter in the parameter to return the error message, and the client can also judge the value of the E.error and E.ref parameters.
Since the project is still under development, I am currently using the third method, which simply adds a ref string errormessage parameter.
Another issue that has recently been considered is how to drastically reduce the number of WCF services and instead design the widest possible service interface. Even at the expense of a strong type is worthwhile, as long as the design of their own serialization/deserialization mechanism on the line. Because updating WCF references can be cumbersome and error-prone. In the case of a business system, where there are many data tables, the traditional approach will require more Service to do CRUD operations. In this respect, if any friend has good idea, also want to share.