Channels 130: Configuration support

The final piece that we need to add to our Transport is configuration support. To expose our transport through config, we need to implement two configuration sections.

Binding Element Extension Section

The first class we add is to configure UdpTransportBindingElement. This is so that custom binding implementations can include udp. In UdpTransportSection we define our configuration section name (how we are referenced from config), the type of our binding element, and how to create our binding element; all with just a few simple overrides. We can then register our extension section in a .config file as follows:

    <add name="udpTransport" type="Microsoft.ServiceModel.Samples.UdpTransportSection, UdpTransport" />

And it can be referenced from custom bindings to use UDP as their transport:

    <binding configurationName=”UdpCustomBinding”>

Binding Section

The second class we add is to configure SampleProfileUdpBinding, our “standard binding”. Through SampleProfileUdpBindingSection we expose this binding to the configuration system. Most of the methods delegate to SampleProfileUdpBindingConfigurationElement, which derives from StandardBindingConfigurationElement.

SampleProfileUdpBindingConfigurationElement has properties that correspond to the properties on SampleProfileUdpBinding, and functions that map from the ConfigurationElement to Binding and vice-versa.

Finally, we need to override the OnApplyConfiguration() function in our SampleProfileUdpBinding:

protected override void OnApplyConfiguration(string configurationName)

SampleProfileUdpBindingSection section = (SampleProfileUdpBindingSection)ConfigurationManager.GetSection(UdpConstants.UdpBindingSectionName);
SampleProfileUdpBindingConfigurationElement element = section.Bindings[configurationName];
if (element == null)

throw new ConfigurationErrorsException(string.Format(CultureInfo.CurrentCulture, “There is no binding named {0} at {1}.”, configurationName, section.SectionInformation.Name));





To register this handler with the configuration system, we add the following section to a .config file:

  <sectionGroup name=”system.serviceModel”>
   <sectionGroup name=”bindings”>
    <section name="sampleProfileUdpBinding" type="Microsoft.ServiceModel.Samples.SampleProfileUdpBindingSection, UdpTransport" />

It can then be referenced from serviceModel config:

   <endpoint configurationName=”calculator”

contractType= “Microsoft.ServiceModel.Samples.ICalculatorContract”>


The result is a completely functional third party transport that can be used in any Indigo program!

2 thoughts on “Channels 130: Configuration support

  1. Matias Woloski

    Hi Kenny,
    this series of posts was very useful. I found myself in the task of implement an interception mechanism in Indigo that would need to change the response output.

    Indigo client –> my interceptor –> Indigo service –> my interceptor –> Indigo client

    I’ve started implementing my bindingelement and succesfuly implemented the proxy side with channel factories. However, the listener side was more difficult and I abandoned and decided to go with IStubMessageInspector which was much more easy to implement. Maybe I was using the wrong strategy, but I think there should be more documentation and examples regards the different interfaces provided (IOutputChannel, IRequestChannel, IReplyChannel, etc). I didn’t know which one I would need in my bindingelement.


  2. Kenny

    For your case Matias, I think the IStubMessageInspector is exactly what you were looking for. Implementing at the Channel Layer, while not rocket science, is certainly more complicated and less documented (for now). I’m working on a few more examples (like Remoting for RequestReply, or TCP for DuplexSession) and can try and post more about the channel shape differences. If there are particular items that tripped you up, please let me know.

    Thanks for the feedback!


Leave a Reply

Your email address will not be published. Required fields are marked *