A WCF Review and how to Debug it

A comment

At some point, people need to understand that, business applications are not like console applications. So all these comments on the net, in blogs and forums, should be a little more double checked for real life development process because they mislead other people. Especially for LINQ to SQL and WCF, I am really bored reading about how great they are and how easy they are, but the truth is that LINQ to SQL is not for applications mainly because it is not thread safe and other related problems(explanation).Sadly I was one of the victims that tried to adopt it. WCF although is great, it can also be a pain in the ass. When searching through the net, keep in mind always that Internet is not always correct as I have wrote here. I really suspect that many of the blog post although, they can be helping, are not revealing entirely the truth and the disadvantages. I have always been fun of Microsoft Technologies but there is a limit to the indirect advertisement.

Following Instructions

Back to the post subject. Many of you have done what everybody on Internet says. Add a WCF Service and a Service Reference and Great, all is ready and done. Even for debug, every time I execute debug the application, a dummy Debug Host is raised and I can debug the service. All is great? No.

Questions

First of all. What if I’m not running parts of the solution that require the service. Why should I be punished with the overhead of raising the host?

Second and most serious. Has really anyone tried to debug the service, and every underlying class used by it? Has anybody tried to utilize edit and continue, among all these guys who say how great WCF is?

I tried and as you can guess from my attitude, I could not utilize Edit And Continue. When I am developing a big Application, usually there will be at least 2 layers behind the service. Should I restart the application each time? And don’t let me talk about the debug through the dummy client, when an Operation Contract of mine, will use a complex data type. It is just not possible.

So what is the solution?

Easy someone can say, but easier said than done. As you would with .Net Remoting, If the service is located in your output directory, by whatever trick in the solution, then just raise the host programmatically in an address of your choice and then tell the client to hit this address. This way you have always simulating data transferring through WCF channels (very important), and you can of coarse use the feature of Edit and Continue.

The problem is that the dummy service the solution raised keeps coming up, which is very annoying. I haven’t found a solution, mainly because in the framework I’m developing, there is a single Operation Contract handling abstract Message Types. This was another great milestone for me in WCF. I really can’t understand why they have made DataContractSerializer as complicated, and not simple as the one used in plain old fashioned remoting. Having this service in my framework, I do not have in my solution the WCF Service so , there is no penalty overhead from the Debug Host that is raised.

Last Problem

Finally a point of interest which was my last obstacle that took me a half day to find. I had implemented a provider class for the remoting part, which if needed, fired up the service host. Everything worked just great in the test projects, but at some point I tried to extend the framework with WPF.

The trick was that at first request, through static constructor I checked if the service was required to be hosted, and did that. But this did not work when I made the call from WPF. The only error was a timeout exception. I was going crazy, and then it kicked in. Never trust completely a 3 party library.

Solutions

I made three clients, one Console, one Windows one WPF and stripped down the functionality of my framework to test. On each UI Client I made the call (and raised subsequently the host) after a UI reaction. I turns out that neither Windows Forms played correctly, when for example the call is made through a button click event. When I saw that, I made the host come up before the UI part was ever initialized and guess what? It all played just fine.

I really can’t understand how this has not been mentioned.

Conclution

For me WCF is good for the plumbing. It is much more complicated than .Net remoting, really hard to troubleshoot if you are doing something outside the ordinary, which are discussed in all those praising posts and articles. Maybe I haven’t studied it as much, maybe I’m missing something but if the case is true, tell me how something that is advertised as easy and all remoting-problem solving can be this hard to utilize and debug. You will say that WPF, has as much difficult learning curve but WPF is not advertised as the magic trick that the programming world was missing. Since I have read about it, everyone mentioned that it is hard and difficult to adopt, and it is not for all kinds of applications. For me WPF is the star of .NET3.

Despite all these problems I really believe in WCF, because of other great stuff that it supports. Regarding security MS says here that

You should not use WCF Service Host to host services in a production environment, as it was not engineered for this purpose. WCF Service Host does not support the reliability, security, and manageability requirements of such an environment. Instead, use IIS since it provides superior reliability and monitoring features, and is the preferred solution for hosting services. Once development of your services is complete, you should migrate the services from WCF Service Host to IIS.

Having this in mind, I can't stop thinking whether WCF is a great overhead on development, when .NET is remoting is a well tested solution under IIS. But choices have been made, mainly because the new technology I believe is here to stay.

Links

http://sarafianalex.wordpress.com/2008/06/17/wcf-debuging/

Explanation for LINQ to SQL not suitable for LOB