Click here to Skip to main content
Click here to Skip to main content

A WCF Review and How to Debug It

, 17 Jun 2008
Rate this:
Please Sign up or sign in to vote.
A WCF review from the perspective of bussiness application development, and some debugging problem solving hints.

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 processes 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 has other related problems (explanation). Sadly, I was one of the victims that tried to adopt it. WCF, although is great, can also be a pain. When searching through the net, alsways keep in mind that the Internet is not always correct as I have wrote here. I really suspect that many of the blog posts, although they can be helping, do not entirely reveal the truth and the disadvantages. I have always had fun with Microsoft technologies but there is a limit to indirect advertisement.

Following instructions

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

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 a 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 develop a big application, usually there will be at least two 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 is using a complex data type. It is just not possible.

So what is the solution?

Easy, someone might 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, just raise the host programmatically in an address of your choice and then tell the client to hit this address. This way, you are always simulating data transfer through the WCF channels (very important), and you can of course use the feature of Edit and Continue.

The problem is that the dummy service the solution raises keeps coming up, which is very annoying. I haven't found a solution to this 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. By having this service in my framework, I do not have the solution in the WCF Service, and 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 half a 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.

At the first request, through the 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 completely trust a third party library.

Solutions

I made three clients: a Console one, a Windows one, and a WPF one, and stripped down the functionality of my framework to test. On each UI client, I made the call (and subsequently raised the host) after a UI reaction. It turns out that Windows Forms did not work 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 worked just fine.

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

Conclusion

For me, WCF is good for the plumbing. It is much more complicated than .NET Remoting, and really hard to troubleshoot if you are doing something outside the ordinary, which is discussed in all these 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 solving all Remoting-problems can be this hard to utilize and debug. You will say that WPF has as much a 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 mentions that it is hard and difficult to adopt, and it is not for all kinds of applications. For me, WPF is the star of .NET 3.

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, whereas .NET 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

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

About the Author

aSarafian
Team Leader ALGOSYSTEMS
Greece Greece
I live in Athens Greece and currently I am working with Business scale application with .NET latest technologies
 
I've been developing applications for personal and friends usage with C++ using majorly Borland's various IDEs since 1994.
In 2002 I began working for an R&D institute where I was introduced to C# which I worships ever since.
 
I love core application development and I would like to publish more articles here and on my blog, but there is not enough time to do so.
 
I usualy "waste" my spare time watching sitcoms, preferable SCI-FI.
I would like to play chess but I can't find any real world players to hang out with.

Comments and Discussions

 
Generaltotally agree with you Pinmemberdevvvy12-Mar-09 18:14 
GeneralRe: totally agree with you PinmemberSarafian12-Mar-09 22:25 
GeneralRe: totally agree with you PinmemberSarafian12-Mar-09 22:27 
GeneralRe: totally agree with you Pinmemberdevvvy12-Mar-09 22:32 
GeneralRe: totally agree with you PinmemberSarafian12-Mar-09 23:15 
GeneralWCF is not that simple/easy as it shown PinmemberBinoy Patel19-Jun-08 4:02 
GeneralRe: WCF is not that simple/easy as it shown PinmemberSarafian19-Jun-08 4:51 
GeneralRe: WCF is not that simple/easy as it shown PinmemberBinoy Patel19-Jun-08 6:58 
RantWCF was too much for me. Pinmembertitltn2117-Jun-08 11:51 
GeneralRe: WCF was too much for me. PinmemberSarafian19-Jun-08 4:53 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

| Advertise | Privacy | Mobile
Web04 | 2.8.140721.1 | Last Updated 17 Jun 2008
Article Copyright 2008 by aSarafian
Everything else Copyright © CodeProject, 1999-2014
Terms of Service
Layout: fixed | fluid