ansaurus

Question

Help debugging WCF

Answer 1

+3 A:

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.

John Saunders 2010-09-13 00:00:47

He is, but go eeeeasy on him. :) When you first start doing WCF, your first reaction is "WTF" when you don't get detailed exceptions. But the suggestion for WCF tracing is the key.

Dave Markle 2010-09-13 00:03:12

John, thanks for your advice. I disagree with you on some points, in particular, not using a standard error reporting mechanism (i.e., exceptions) *does* count as error hiding in my book. If my application is not working, I shouldn't have to play hide'n'seek to find out why.

Rafe 2010-09-13 05:59:02

As for serialization errors, I want the RPC mechanism to *guarantee* that these cannot happen. That is the whole point of having a statically checked type system. Moreover, I cannot upgrade the server side of the interface independently of the client side. I certainly do want to update both at the same time.

Rafe 2010-09-13 06:00:38

I'm sure you're correct that WCF is marvellous. However, I challenge you to explain how the default error reporting behaviour is helpful. The error messages in the event log might as well have been written in Martian.

Rafe 2010-09-13 06:04:39

Just to give my mild ranting some context: nearly twenty years ago I worked on/with the ANSA and Corba RPC systems and my recollection is that they made it very clear when things went wrong.

Rafe 2010-09-13 06:08:08

@Rafe: WCF uses exceptions. What are you talking about? Also, the world is way past CORBA, which died for very good reason. WCF is not an RPC system, it is a platform for creating SOA-based applications. The more you expect it to be like CORBA, the more you'll be fighting the tide.

John Saunders 2010-09-13 11:55:39

Answer 2

+1 A:

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.

Andrew Shepherd 2010-09-13 00:03:46

Many thanks for that advice, Andrew; I'll check it out as soon as I get a chance.

Rafe 2010-09-13 06:08:31

Answer 3

+1 A:

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.

Ladislav Mrnka 2010-09-13 08:20:45

Thank you for your reply and I would appreciate it if you could explain further, since the points you make I have heard elsewhere. (1) How is WCF different from asynchronous RPC? Each operation has a name and a signature (*these* are the arguments with *these* types and *this* is the result with *this* type). If I change this specification I cannot see how clients can continue to interact with my service. (2) The interface is strongly typed. WCF knows exactly what types are involved. If I pass an int where a string is expected, I really *should* get an error indication saying so.

Rafe 2010-09-13 12:03:23

[cont.] (3) If my service or client tries to send more data than the channel is configured to transmit in a single message, it should tell me that also. I can see how allowing *any* exception to cross the interface is bad, but I can't see how explaining in what ways a request is ill formed or cannot otherwise be serviced grants an attacker useful information.

Rafe 2010-09-13 12:07:11

That said, I will certainly try out your advice - much obliged. WCF is surely a great tool, I've just been pulling my little remaining hair out trying to fathom why my application hasn't been working.

Rafe 2010-09-13 12:08:25

There is generally no difference between WCF and RPC because you can create RPC like Web service in WCF. It is just application of WCF. But you can also create SOA service or REST service - such application is not possible with RPC like remoting. But still RPC like Web service is more contract oriented. Contract is in interoperable format (WSDL + XSD) so you can write service in .NET and consume it in Java in easy way.

Ladislav Mrnka 2010-09-13 18:59:37

There are certain rules for versioning. You can't change operation name but you can remove not required parameter or add not required parameter. If you pass the int where string is expected you get exception unless you are working on raw messages where no interface is used. Defense against DoS attack works as is. It is exactly same in IIS or ASP.NET. If you exceed limit you simply get Bad request.

Ladislav Mrnka 2010-09-13 19:04:23

ansaurus

tags:

views:

answers:

Help debugging WCF

related questions