Help debugging WCF

I am new to WCF programmin开发者_运维知识库g and am finding the learning process rather frustrating. As far as I can tell, WCF (and WPF, for that matter) will hide errors from you by default. So far I have experienced the following problems and had essentially zero indication from Visual Studio or the runtime that there was anything wrong (other than my application just not working):

• a service reference not being up-to-date (why doesn't VS do this automatically?);
• a type in a service method could not be serialized;
• the service was trying to pass more data than the defaults allow.

Presumably there is some simple way of making these problems visible to me, the developer. If anyone can tell me what it is, I would be very grateful (hours of googling have not provided a working answer)!

I would also appreciate an explanation, if anyone knows, why the default behaviour for WCF and WPF is to quietly hide errors like this. It seems bizarre, to say the least.

I guess you have missunderstand elementary ideas of Web services. WCF is API for building web services. Web services in contrast to RPC are supposed to be used independently. It means that you can create web service without knowing the application which will used it (you can expose web service to Internet or to business partner). It is a big difference to RPC where client and service are most of the time built together. Based on elementary security practices service exceptions are not send to client by default. You don't want to expose internal information to your unknown clients.

To your questions:

Service reference is not up to date: Yes this is very important for versioning. I can build new version of web service and use the old client code. If you are building both client and service and you are sure that new versions of client and service will be always deployed in the same time you can use Andrew's suggestion.

Type can't be serialized: Web services are using interoperable format for data exchange. How do you think the compiler should know if the type is serializable? Should it run the serialization of all data types during each build? As John suggested this can be easily discovered by proper testing strategy.

The service tryes to pass more data then client allow: What do you mean by that? Do you mean that service can pass additional fields which are not known to client because of new version of the service? In that case you are complaining about one of the most important versioning features. Or do you mean that service can send bigger message than client allows? In that case how should the service know what size is allowed on the unknown client? MaxReceiveMessage size is defence against Denial of service attack and it is controlled by receiving side. If you need to handle dynamic message size in your communication you have to code it.

Hiding errors: By default each service has this configuration in its behavior:

<serviceDebug includeExceptionDetailInFault="false" />

Simply change this to true add WCF Tracing + socket tracing and WCF Message logging and you will get the best diagnostic arsenal MS has ever provided in .NET to developers.

You are completely mistaken. WCF does not hide errors from you. You must simply not be looking in the right place.

Have you looked in the Windows Event Log (Application)? Have you turned on WCF tracing?

It is necessary for you to control the time at which a service reference is updated. Just because you have changed the contract does not mean that it is time for every reference to the contract to be updated. Updating a service reference may require the client code to be changed, and quite possibly, will require it to be tested again.

How do you expect to learn about a serialization error without serializing? If you want to be certain that your serialization works, then create a unit test that serializes!

In general, WCF works well. Like any technology, you are more likely to find frustrations while you are learning it.

An answer for one of your points:

The "Add Service Reference" functionality is useful for when you yourself are not writing or maintaining the service contract. If the service, the client, and the service contract are in the same solution, it is better not to rely on auto-generated service references. The fact that they don't automatically update is just one reason.

See this presentation for an in-depth look at that.