What project structure do you use for C# apps that host multiple WCF services?

Question

I need a C# WinForms app to host multiple WCF services. So which of these (1 or 2) would be suitable?

1. Should I create a C# WinForms project and another WCF Service Library project?

2. Or simply create a Form in the WCF ServiceLib project? -- Will I still be able to do all these:

   • control service lifetime, set the properties of the service
   • open the service (and set it into a listening mode)
   • close the service

Answer 1

Number of projects to create

There is no problem doing it all in one project. In fact, if the WinForms app is hosting the services itself, it is more convenient to do it in one project because you just have a single .exe file.

On the other hand, if you are implementing separate client and server code, it can be convenient to have the service interface (or the whole service) in a separate dll. That way both the client and server can reference the same DLL.

It's really an architectural decision based on the bigger picture of what you're trying to do. For a simple WinForms exe that hosts a few services, I would generally just use a single project.

What can be done in a WCF ServiceLib project

The default WCF Service Library project produces a .dll, so you'll have to change it to produce a .exe if you want to run it and display WinForms. In your .exe you can do everything in your list. Specifically, in the running application you can:

• change the service configuration
• control whether the service is active or not
• start and stop the service

You can also connect to your own service for testing.

Answer 2

I like to separate my WCF projects out like this:

• a class library with the contracts - all your service contracts, data contracts etc. If your solution gets large, this might even be several class libraries, each handling one area/topic of your solution
• a class library with the service implementation - again, if you have lots of services, maybe you'll even go for several class libraries

• a Winforms or console app as service host - for testing and debugging purposes

• a class library for the client proxy/proxies - again, if it makes sense, this could be several libraries even - one for each "logical subsystem"

• and finally your actual client - a Winforms, WPF, whatever app that actually consumes and uses those client proxies

The reasoning behind this is that I want to have a clear separation of concerns - since the services share nothing but the contracts (service and data contracts) that belongs into a separate assembly. Since the service host really has nothing to do with the service impmlementation, these two should be separated as well.

In your case, you would have your Winforms app (or apps) be the actual service hosts - e.g. your would instantiate a ServiceHost class inside your Winforms app, and host the appropriate service (from the services assembly) inside that ServiceHost - and of course, you can have as many service hosts as you need! (one per service you need to make available)

On the client side it pays off to put the proxies into a separate assembly since that assembly can now be shared amongst several client projects while having the code in just a single location.

And since I have the contracts in a separate assembly, as long as I control both ends of the .NET-to-.NET communication, I can actually share that assembly between the server and the client and reuse the same types - instead of having the client create its own, separate data types.

A lot of those things are taken from Miguel Castro's excellent Extreme WCF screencast - definitely worth a look! (same goes for Keith Elder's Demystifying WCF - also excellent stuff!)