Contract first WCF service (and client)
NOTE: This post is kept here for historic reference, and while this still presents the cleanest way to set up WCF, a shared library model is not in line with modern microservice architectures
There seems to be a popular misconception stating WCF is obsolete/legacy, supposedly because it has been replaced by new techniques like ASP.NET WebAPI. For sure: since WebAPI was created to simplify the development of very specific - but extensively used - HTTP(S) REST services on port 80, it’s clear if you are developing a service exactly like that, you would be foolish to do so in WCF (since it’s just extra work).
However, to state a technology is obsolete because there is a better alternative for a very specific use case when there are over 9000 use cases which no other tech addresses is silly. Your personal bubble might be 100% web, but that doesn’t mean there is nothing else: WCF - unlike WebAPI - is a communications abstraction. Its strong point is versatility: if I want my service to use HTTP today and named pipes or message queueing tomorrow, I can do so with minimum effort.
It’s in this versatility where we hit the second misconception: ‘WCF is too hard’. I have to admit I spent quite some days cursing at my screen over WCF. Misconfigured services, contracts, versioning, endpoints, bindings, wsdls, etc. there is a lot you can do wrong, and every link in the chain has to be working before you can stop cursing.
However, that is all with WCF done the classic way, but none of that stuff is necessary if you do it the right way, which is contract first without much/any configuration.
WCF the right way™: contract first
The basic ingredients you need are:
- a service contract in a shared library
- the service: an implementation of the contract
- some testing code (client)
And that’s it. I’ll give a minimal implementation of this concept to show the power and simplicity of this approach below. Did I mention no configuration ?
The service contract
using System.ServiceModel;
namespace Contracts
{
[ServiceContract]
public interface IContractFirstServiceContract
{
[OperationContract]
bool Ping();
}
}
It’s important you place this contract/interface in a seperate - shared - assembly so both the service implementations as well as the client(s) can access them.
The service implementation
using System;
using Contracts;
namespace Service
{
public class ContractFirstService : IContractFirstServiceContract
{
public bool Ping()
{
return true;
}
}
}
That’s all, and the service can now be hosted. This can be done in IIS with a svc, or by self hosting it (in a console app). In any case, we need a ServiceHost implementation, which I’ll place in the service project:
using System;
using System.ServiceModel;
using System.ServiceModel.Channels;
using Contracts;
namespace Service
{
public class ContractFirstServiceHost : ServiceHost
{
public ConstractFirstServiceHost(Binding binding, Uri baseAddress)
: base(typeof(ContractFirstService), baseAddress)
{
AddServiceEndpoint(typeof(IContractFirstServiceContract), binding, baseAddress);
}
}
}
The client (testing the service)
In the following piece of code I’ll self-host the service, open a client and test the WCF call roundtrip.
using System;
using System.ServiceModel;
using Microsoft.VisualStudio.TestTools.UnitTesting;
using Contracts;
using Service;
namespace Tests
{
[TestClass]
public class IntegrationTest
{
[TestMethod]
public void TestClientServer()
{
var binding = new BasicHttpBinding();
var endpoint = new EndpointAddress("http://localhost/contractfirstservice");
// Self host the service.
var service = new ContractFirstServiceHost(binding, endpoint.Uri);
service.Open();
// Create client.
var channelFactory = new ChannelFactory(binding, endpoint);
var client = channelFactory.CreateChannel();
// Call the roundtrip test function.
var roundtripResult = client.Ping();
Assert.IsTrue(roundtripResult);
}
}
}
There you have it: a contract first WCF service in a few lines.