Project Description
ConfigStation is a library that allows developers to host any number of WCF services without having to deal with setting service and client side configurations. The only configuration that is required at the moment is for the Repository service, which can be removed easily.

Updated my blog:


The project has been inspired by my need for developing WCF clusters and by the Configuration Service (from the StockTrader Microsoft sample).

The configuration service is a great library but it is strongly tied to the SQL Server database which by itself is a great shortcoming for many of us. Though the Config Station project is not as complex or as functional as the Configuration Service, it is my mild attempt towards implementing a simple repository.

Future ideas include implementation of Load balancing, Failover and better repository registration and resolution. Right now the repository is store in memory which means when the repository hosting service dies, the registrations are lost. I would love to enhance this segment.

Based on the feedback received, I would consider adding enhancements (or you are welcome to join, just shoot an email to

The source code makes use of the ServiceHost<T> implementation by Juval Lowy in his wonderful book - Programming WCF Services.


1. Hosting the services would be as simple as :

using (var configHost = new ConfigStationHost())
var hostFacade = new ServiceHostFacade<TestImpl>();
var host = hostFacade.Host;
Console.WriteLine("Test service launched.Enter to Stop");

In this case, the ConfigStation is hosted within the same service where the TestImpl wcf service is hosted. You can host the ConfigStation in a different process from that of your service host process, in which case you would not use the "using" block in your host.

The service, at the moment has some WCF configuration which is pretty straight forward. Every application that hosts your WCF services and those applications that are clients for your WCF service should have the following configuration it their app.config.

<?xml version="1.0" encoding="utf-8" ?>
<endpoint address="http://localhost:8731/ConfigStation/Repository" name="ConfigStation"

The address you specify in the <endpoint> element should match with the one specified in the app.config for that process which hosts the ConfigStation.

The app.config for a process which open's the ConfigStationHost (hosts the ConfigStation service) should have the following configuration.


<add key="ServiceScheme" value="net.tcp"/>
<add key="ServicePort" value="9989"/>

<service name="ConfigStation.Repository">
<endpoint address="http://localhost:8731/ConfigStation/Repository"

<!-- if the current process hosts any other WCF service using the ConfigStation, then the following client element is required -->
<endpoint address="http://localhost:8731/ConfigStation/Repository" name="ConfigStation"

Note that the app settings are not required if your application does not make use of ServiceHostFacade to host any other WCF service.

The appsettings - ServiceScheme and ServicePort are only required if you are using automatic detection of service configuration that would be used by the service host generated by the ServiceHostFacade<T> class. You can skip specifying these settings and instead make use of ServiceHostFacade<T>(serviceDetails) class in which case you have to create instance for the ServiceDetails class.


When the source code is available :
1. Compile the solution.
2. First run the "Test.Service" project. Note that if you are running Vista or Win7 with UAC turned on, run the service as administrator. Or if you do not wish to run the service as Admin, please follow the article to set up your machine such that AddressAccessDeniedException is not encountered.
3. Now run the Test.Client project. This does not require running as Administrator.

Note that the ConfigStation.TestClient is used to demonstrate hosting the ConfigStation in a separate service.


1. I am no WCF expert - which might make the ConfigStation library implementation not efficient. I am not a great s/w architect - which might make my code horribly designed. I would appreciate if someone volunteers to perform a generic code review with advice on the areas of improvement.
2. At the moment, using this library to host the WCF service blocks the configurability that Microsoft provides in the WCF framework. I would implement a hybrid which allows you to host WCF service with behaviors, security, etc be defined by the developer, in an easy to use fashion.
3. The auto-generation of ServiceDetails uses the first interface implemented by a WCF service which contains the ServiceContract attribute. This would be fixed in the future releases to make it more predictable. The whole auto generation of service details would be revised.

For feedback, use the discussions forum or email at

Last edited Aug 29, 2009 at 1:16 AM by truebuddi, version 5