WCF services development made easy in VS 2008?

Or what?

Yes, I am C++ maniac and would write everything in C++, if I could, but I am not an idiot. I have written distributed network applications in C++ before, this is why for a new project I decided to see how .Net eases such tasks.

That’s true — Windows communication foundation looks pretty good. It’s straightforward, it hides all network stuff behind and even newly released VS 2008 has sufficient project templates that make WCF services creation as easy as can be.

As it turned, not quite. If you really want to create distributed network system where different systems and programming languages may be involved, better consider ICE (www.zeroc.com), for example. At the moment I am busy testing and comparing performance of all such libraries I can find and ICE is at least as twice as faster than WCF using TCP binding. And you know what? Writing ICE server and client parts is even easier than dealing with WCF, not mentioning that I could write server in C++ and .NET client for it in half an hour. The only issue is that there is no wizards for ICE built in VS.

Only a few clicks and you’ve got a fully functional skeleton for the service — just add some business logic and you are ready to go. Even more, new studio helps you debug these services — as you try to run it (remember trying to run a DLL project in Studio 2003 and scary error messages?) Studio kindly starts a process that hosts your service (WcfSvcHost.exe) and shows a nice client that allegedly helps you debugging that service. Isn’t it what we all were dreaming about? Finally, distributed application development became really easy!

Well, it wouldn’t be a Microsoft creation if there were no hidden surprises. In this case, great feature of Studio that allows developer to start a newly created WCF service without a hassle of writing hosting application by her- or himself may become a nightmare.

Studio tends to host and start all WCF services from current solution even if you want run and debug completely different project which may not use any of those services at all! It just does it because these projects are there. And it gets worse when the application consists of a few WCF service projects and Windows or console or NT service project that, as developer intended, should host these services in production. Just imagine — you want to see if your program starts and starts these services, but before you see it running, you’ll watch notification that «Your service(s) have been hosted». Then you realize that all your services are hosted somewhere else but not by where you wanted them to be. If you did not modify service entry point in App.config, you’ll see exceptions coming through as «another application has already registered that address». Of course, it did. WcfSvcHost.exe did it for us.

I tried to find the way of switching it off but all my efforts have failed. I found a post with similar problem and the only answer was

If the WCF projects are in the same solution as your WPF app, the debugger will also startup your services. This makes the debugging experience simpler where you can simply set a breakpoint in the WCF service and break whenver the WPF app calls into the WCF service.

Isn’t it pretty? It makes debugging simpler! But who says I was going to debug anything?

I wouldn’t be debugging anything at all. I forgot how to use debugger — for a last few years I completed several projects (in C++, by the way) and they did not have any memory leaks, crashes, performance problems and other nasty things. Without using debugger at all. I just prefer unit tests.

That’s all — great idea, nice project template, but a little feature that breaks everything apart.

Or I just missed a check box somewhere?

No, I did not. All my efforts to stop VS from starting WcfSvcHost.exe each time I run any project were fruitless. But I could stop it from hosting services by removing (or making invalid) app.config in corresponding projects. At least it prevents hosting process from starting the service and occupying a port which I was going to use.

Upd: Just found similar question and possible workaround:

you can remove the ProjectTypeGuids tag from the project file as a workaround.

Another update: After some research I found a way to consume WCF service with unmanaged C++ client.

  1. Awesome!!! The ProjectTypeGuids removal worked. This was driving me insane

  2. If your project is a «WCF Service Library», your project settings should include a «WCF Options Page» that has only one option, «Start WCF Service Host when debugging another project in the same solution». Perhaps it would help to turn that off.

Оставить комментарий


Примечание - Вы можете использовать эти HTML tags and attributes:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

15 посетителей онлайн
6 гостей, 9 bots, 0 зарегистрированных
Максимум сегодня:: 20 в 12:49 am UTC
В этом месяце: 53 в 09-21-2021 08:53 am UTC
В этом году: 248 в 07-26-2021 10:24 am UTC
За все время: 332 в 11-22-2019 03:23 am UTC