WCF: Hosting a Basic WCF Service in IIS

Okay, so you’ve made a wonderful WCF Service. It tells the time and everything! But how do you use it? Well, that’s where things get a bit complicated.

There are many ways you can host this service, and many ways clients can access it. You can host the service in a stand-alone application, or in a Windows Service you’ve written. You can use something called Windows Process Activation Service. Or, you can use good old IIS. Using IIS has a few nice advantages: you get to use all the power and configuration of IIS, it’s easy for people to understand what’s happening, even if they don’t know WCF, and it’s easy for other applications to use the service – even if they’re not built with .NET.

You also have to choose a binding. A binding is essentially a means of communication, and there are many to choose from. You can choose HTTP (in many flavours), TCP, named pipes, MSMQ, and so on. We’re going to look at basicHttpBinding, which is nice and simple to work with and highly compatible.

So, if we’re hosting in IIS, we clearly need a virtual application folder in which to run our service. Let’s call this web WCFTest. Then, use IIS Manager to allow anonymous authentication so we don’t have to worry about security concerns for the time being.

We’ll need to add three files to our web. First, we need the assembly containing the service you wrote. I’ll assume you created the service I showed you last time, and you put it in a class library (DLL project) called WCFTest. When you compiled that project, you made a file called WCFTest.dll. Create a folder called ‘bin’ in your web, and copy this file there.

Second, we need to add a .svc file to the web. This file represents the address that clients will use to access the service, and it tells IIS where to find the service to use. Let’s call this file Test.svc. It needs to contain the following:

<%@ ServiceHost Service="WCFTest.Test" %>

ServiceHost tells the server that this URL represents a WCF Service. Service="WCFTest.Test" tells the server what class to use to run the service. Because we put our .dll file in the /bin folder, the server will automatically find the class and be able to use it. There are other ways of organizing this, but this is perhaps the simplest to understand.

Finally, we need a web.config file placed in the web’s root to tell the server how to configure the service. Here’s what you need:

<?xml version="1.0"?> 
<configuration> 
 
  <system.serviceModel> 
    <services> 
      <service  name="WCFTest.Test"> 
        <endpoint address="" binding="basicHttpBinding" contract="WCFTest.Test" /> 
      </service> 
    </services> 
  </system.serviceModel> 
</configuration>

You can see that we’ve configured one service, called WCFTest.Test, and we’ve created one endpoint using basicHttpBinding. You can see that for the contract we’re using the same class as the actual service itself, but if you want, you could define the service contract (as an Interface) in one assembly and then implement the service itself (as a class that implements your interface) in another class or assembly.

Now, when you browse to http://localhost/WCFTest/Test.svc, you’ll see a web page that states you’ve accessed a WCF service. The rest of the page talks about metadata. Right now, your service is up and running. If you had any clients using the service, they’d be working.

But: you don’t have any clients using this service. And without metadata, you’re going to find it tough to build one. Metadata tells other programs how your service works and how to use it. Once they know this, they don’t need the metadata anymore, but to get there, we’re going to expose the metadata through IIS. To do this, we’ll change our web.config file to add another endpoint. This endpoint will use mexHttpBinding, which is a metadata exchange format. We’ll set the address to /mex, and we’ll also define and set a serviceBehavior, which allows you to specify more detailed options about how your service works. Here’s how your new web.config file should look:

<?xml version="1.0"?> 
<configuration> 
 
  <system.serviceModel> 
    <services> 
      <service behaviorConfiguration="basicBehavior" name="WCFTest.Test"> 
        <endpoint address="" binding="basicHttpBinding" contract="WCFTest.Test" /> 
        <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> 
      </service> 
    </services> 
    <behaviors> 
      <serviceBehaviors> 
        <behavior name="basicBehavior"> 
          <serviceMetadata httpGetEnabled="true" /> 
        </behavior> 
      </serviceBehaviors> 
    </behaviors> 
  </system.serviceModel> 
</configuration>

Now, metadata about your WCF service is available at http://localhost/WCFTest/Test.svc/mex. You won’t be able to browse it with Internet Explorer, though; it’s not meant to be used by a web browser. You can, however, browse to http://localhost/WCFTest/Test.svc?wsdl to see an XML version of your metadata.

At this point, your service is up and running in IIS, and metadata about your service is available so other programs will know how to access and use it.