The difference between Visual Studio’s WCF Service Application and WCF Service Library project templates

I’ve been working with WCF lately. One of the immediate points of confusion was which type of project to start out with: WCF Service Application or WCF Service Library. Let’s take a look at each, then examine the differences. Hopefully we can come to some conclusion regarding the time and place to use one or the other.

The WCF Service Application Template

You create a WCF Service Application by way of Visual Studio’s “Add New Project” dialog:

image

The end result is this:

image

It’s no coincidence that the structure is similar to that of a web application. Specific to the WCF service, you have the service contract (IService1.cs), service implementation (Service1.svc.cs), and the web configuration file (web.config). In addition, we get a service host file (Service1.svc).

The WCF Service Library Template

Similar to the Service Application template, you create a WCF Service Library by way of Visual Studio’s “Add New Project” dialog:

image

This produces a project tree as:

image

Much like the WCF Service Application project, a service library has a service contract (IService1.cs) and service implementation (Service1.cs). Instead of a web configuration file, though, we have an application configuration file (app.config). Also, no service hosting file.

With regard to the app.config file, MSDN states:

Visual Studio is configured to recognize the App.config file as the configuration file for the project when it is run using the WCF Service Host (WcfSvcHost.exe), which is the default configuration.

So what’s the diff?

If you do a file comparison between like files you’ll find the code is identical. Even the Service Application’s web.config and Service Library’s app.config are nearly the same (when looking at just the <system.serviceModel> sections). Also, both projects, when compiled, produce DLL’s.

Perhaps the best way to illustrate the major difference is to run each project.

First, running the WCF Service Application gives us the usual “Debugging Not Enabled” dialog just like any other web app:

image

Click-through that and you get the default directory listing:

image

Click on the Service1.svc hosting file to see the actual service:

image

As one might expect, the Service Application runs just like any other web app and is, in fact, hosted by default by the ASP.NET Development Server:

image

Side note: One bit of puzzlement came when I also saw the WCFSvcHost app come up when running the WCF Service Application (NOT the Service Library):

image

Turns out there is an option in the Service Library project that says:

image

Un-checking that box keeps WcfSvcHost from coming up when I’m running another application in the solution.

End side note

OK, now let’s run the WCF Service Library and see what happens. It’s hosted not by the development server, but by the WCF Test Client:

image

Why is this? Because the Service Library project does not, by default, have a service hosting file or a web.config. You can remedy this by adding each, but then you’re essentially creating a WCF Service Application, right?

This gets us back to the original question, which I think can be answered inasmuch as the web hosting option is concerned with a definite “not much”. Whether you choose Service Application or Library, you still need a .svc hosting file (you’ll have to create one manually for the Service Library project), you still need to move the <system.serviceModel> config info from the WCF project to the web app config, and you still need either the codebehind file (from the Service Application) or the dll (from the Service Library).

The only reason I can see for going with a WCF Service Library is if you want to host the WCF service in something other than IIS, like, for example, a Windows service.