Microservices are a hot architecture concept right now, and we hear a lot of interest in the architecture concepts. Many of the ideas and capabilities behind microservices are already possible with the WCF frameworks for client and server creation. There is one tenet about microservices that you can not do with WCF: run inside of a container. Until now… In this article, we’re going to take a look at running a simple WCF self-hosted service inside of a Docker container.
The architecture that we are going to assemble in this article is quite simple: our self-hosted HTTP service will run inside of a Docker container on our workstation and we will be able to use a client on the same machine to connect through the container and interact with the service. The following diagram illustrates the desired configuration:

Architecture of our sample
WCF Services Run on Windows
WCF runs on the .NET framework, which means that it only runs on Windows. Fortunately, we have Windows Server Core images available to us. If we install Docker for Windows on Windows 10 or Windows Server 2016 with container support enabled, we can configure Docker to use Windows containers. Right click on the Docker whale icon in the system tray and you can choose to “Switch to Windows Containers” to get started:

Switch to Windows Containers
Lets open a command prompt and grab a copy of the Windows Server Core docker image to get started:
docker pull microsoft/windowsservercore
We will build our minimal set of WCF requirements on top of this image.
Our WCF Sample Code
Let’s build a simple service to add to a container and then a client to consume the service from the container. I will start with a service library project that is almost identical to the default project template for a WCF Service Library. I will simply change the GetDataUsingContract method to interpret the StringValue with a slightly different string:
We can then add a simple Windows Console application to the solution that will serve as the host of our service. The Program class is simple and references the Service1 type from our ServiceLibrary project:
The app.config for this project needs to contain some information about the address, endpoint, and behaviors of our service. Lets fill that out with some simple MetadataExchange and BasicHttpBinding:
Finally, we need a client that will connect to the service and interact with the IService1 service contract. This is another Windows Console application. This time we add a service reference to the project and point to the MyServiceLibrary project. My solution looks like the following:

My Solution Explorer
When I add the service, I right click on the WCFClientBasic project and choose “Add – Service Reference” which brings up the following dialogue:

Add Service Reference
I clicked “Discover” and located the entry from MyServiceLibrary to add to the WCFClientBasic project. With that reference added, I can write some simple client code to connect to the service and demonstrate some basic data interactions:
With that code in place, that simply creates a client connection to the Service and executes the GetData and GetDataUsingDataContract, we can run this sample client code in the Visual Studio debugger and verify that it works.
Deploying the WCF Host to Docker
I’ll start by creating a publish folder on disk inside of my solution. Next, I’ll take the simple host application and copy the EXEs, DLLs, and config files into a folder named bin within the publish folder. I’ll then create a Dockerfile at the root of publish with this content:
This file directs Docker to add the WCF-HTTP Activation feature to Windows Server Core, and then copy our host content to the c:\app folder. It exposes port 83, as was configured in our host’s app.config file earlier. Finally, it launches the BasicHttpHost application. We can build this Dockerfile into a Docker image by executing the docker build command like so:
docker build -t wcfhost:latest -t wcfhost:1 .
This creates an image called “wcfhost” with a version of 1 that is also tagged as the latest version. This build step will take a few minutes for Windows to configure the WCF features inside the container. Once complete, you can launch an instance of your host with this command:
docker run -itd --name host wcfhost
We can then inspect the container to determine the IP address of our service. We can use a format string to grab the IP address directly from the container information:
docker inspect -f="{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}" host
Copy that IP address into the app.config of the WCFClientBasic project and update the endpoint address from localhost:83 to your ip address (mine was 172.19.18.87). You should then be able to run your WCFClientBasic and have it attach to the container, returning the expected text results in a console window:

Results from Docker
Summary
We’ve shown how WCF services can be configured using the standard WindowsServerCore container image. There are other Windows options and features that can be configured in this container, based on your service’s needs. The container architecture allows us to scale our service easily as well as deploy the same binaries and configuration that we run in development and staging into a production environment.
Is this something that you might use with your existing WCF services?
The WCF team is working on simplifying Docker integration with service creation and debugging. We would like to hear from you about how you use WCF services and what you want in a containerized WCF solution. Let us know your thoughts in the comment area below and we’ll follow up as we work to bring container support to WCF.
Great article Jeff! Really nice to see WCF getting some love. We built most of our current architecture around WCF, like many other enterprises.
One question, do Windows containers in Docker have a GOLive or similar license yet and/or is still still in a preview state?
Thanks!
I thought WCF is doomed. Did I get it wrong?
WCF continues to be actively developed and maintained. It is a very mature and capable service framework that we continue to invest in.
This is just the beginning of our investigation with containers, and we plan to add more facilities to WCF and WCF tooling to better support container interactions
Great article, keep up the good work.
I’m very glad WCF is going forward 🙂
Just wondering if it’d work with netTcpBinding and duplex services? As we use it heavily in our solution
We are actively looking at building base WCF images and facilities for all WCF features. netTcpBinding and duplex services are on our roadmap
Thank you! I am looking forward to try this. Even before I begin few quick question(s) to avoid frustration. Is every tooling mentioned here is free? And will I be able to perform all of this on Windows 10 desktop at home?
I have been working on Microsoft Tools and Technologies for long and want to keep abreast with developments but never got small enough bite to chew. This one seems good candidate.
No docker support on Windows Home edition 🙁
Can I host WCF application with KestrelHttpServer over AspNetCoreModule. Would be nice if WCF get rid of System.Web (IIS) dependency!
WCF services are only available on Windows and depend on System.Web
WCF services do not really have an IIS dependency. You can pretty much create your own WCF host as a Windows service or as a console app (for testing purposes) and communicate with the clients over TCP/HTTP/MSMQ channels.
This really fits with the choices many teams made back when WCF was the new way to communicate. That code is still out there and most times is deployed on servers that are brittle and old, with no one actually remembering how they were built (i.e. pets). This isn’t necessarily WCF’s fault, but just an artifact of how things were done. Keep moving in this direction, Jeff, and I can see teams pick this up to start moving towards a reliable (cattle) architecture suitable for cloud, but even just to get the on-premises datacenter wrangled.
Sure, new code is ready to be built with Docker and Http based services and whatever is hot NOW. But there is a legion of code built on WCF (SOAP did become the standard for some business processes, and WCF makes SOAP simple).
One thing that can really help is how you showed that it can be super simple to bring an image up with Server Core and add JUST the features you need. Believe me, many Windows shops still put full GUI on and have detailed scripts (in Word) and standard installed components (more surface area than needed for that image, but easier to manage on the whole). We need to get out there and get people used to installing on Server Core and just adding the features needed. A Docker based architecture on Server Core images is definitely forcing that.
Thanks Jeff. Can’t wait to try this out and see more.
Great article. I wanted to know if WCF server components, like ServiceHost, are being added to .Net core and if so what is the time frame for release. If not how can people who are interested in this reach out to the WCF team to let them know this is a direction that WCF should take.
Thanks for the reply David. We are measuring the interest in WCF services on Core, and I don’t believe the topic is completely off of the table. Please add an item to the ASP.NET UserVoice to make your voice heard about what features you would like on Core
One of the expectations of using containers is that all files in the container are identical. The only thing that differs between instances are the configuration, which is controlled through the container, not by changing a config file in the contents. Is there a reasonable way to control the WCF endpoint addresses, if not all of the configuration, through environment variables and such, instead of config files?
BTW, I love WCF and want to continue using it over whatever the new “hottest” technology is at the moment, but that is getting more difficult to do as we are being pushed into using containers and other non-Windows-centric platforms. I hope that WCF will find a home in .Net Core, so that it is not lost to the world.
There is no off-the-shelf support for controlling WCF service endpoints (and other service parameters) via environment variables but it is trivial to implement a mechanism that reads these settings off pre-defined environment variables during the service hosting and configures the service accordingly.
I’m glad I found this post, that means I am not entirely alone in running WCF this way.
One potential fly in the ointment: certificates and https. The configuration of https is to my recollection not entirely straightforward. I put in code, years ago, to make sure I use the correct binding, and I have had installations actually go through with TLS, but I do not quite see how it would fit in with a standard container shipped to various environments.
I guess one could EXPOSE both a http and a https port and pass along a certificate as a parameter of sorts and finally have a script inside the container do the necessary lifting to get that certificate in the right place. Maybe it would even be appropriate to perform some letsencrypt magic there to renew the certificate automatically… (or maybe that would be outside the scope of what is expected of a container)
That said, it seems as if containers are going to solve quite a few of my headaches, so I was very grateful when it finally dawned on me that VS2017 comes with built-in docker support.
Is this deployable via Docker on Linux, or is it still Windows-only?
Windows only..