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
