Rory Primrose

Learn from my mistakes, you don't have time to make them yourself

View project on GitHub

Unity dependency injections for WCF services – Part 2

Posted on May 17, 2010

In Part 1, I described the code used to leverage ServiceHostFactory to create WCF service instances with dependency injection via Unity. Using a custom ServiceHostFactory is a really easy way to get dependency injection in WCF but comes with two drawbacks. The standard Unity configuration section name (“unity”) must be used and named Unity containers are not supported. Most applications will work within these constraints.

Using a configuration based service behavior is the answer to situations where these constraints are a problem. The UnityServiceElement class is used to define the configuration support for the UnityServiceBehavior. As outlined in the last post, the UnityServiceBehavior class is used to assign a custom instance provider to each endpoint in the service. The instance provider is used to resolve a service instance from a Unity container.

The UnityServiceElement class looks like the following. The UnityServiceElement calls into a UnityContainerResolver helper class to resolve the unity container. The code for UnityContainerResolver can be found here.

using System; 
using System.Configuration;
using System.Diagnostics.Contracts;
using System.ServiceModel.Configuration;
using Microsoft.Practices.Unity;
namespace Neovolve.Toolkit.Unity
    public class UnityServiceElement : BehaviorExtensionElement
        public const String UnitySectionNameAttributeName = "unitySectionName";
        private const String UnityContainerNameAttributeName = "unityContainerName";
        private ConfigurationPropertyCollection _properties;
        public override void CopyFrom(ServiceModelExtensionElement from)
            Contract.Requires<ArgumentException>(from is UnityServiceElement, "The from parameter is not of type UnityServiceElement.");
            UnityServiceElement element = (UnityServiceElement)from;
            UnitySectionName = element.UnitySectionName;
            UnityContainerName = element.UnityContainerName;
        protected override Object CreateBehavior()
            IUnityContainer container = UnityContainerResolver.Resolve(null, UnitySectionName, UnityContainerName);
            return new UnityServiceBehavior(container);
        public override Type BehaviorType
                return typeof(UnityServiceBehavior);
        public String UnityContainerName
                return (String)base[UnityContainerNameAttributeName];
                base[UnityContainerNameAttributeName] = value;
        public String UnitySectionName
                return (String)base[UnitySectionNameAttributeName];
                base[UnitySectionNameAttributeName] = value;
        protected override ConfigurationPropertyCollection Properties
                if (_properties == null)
                    ConfigurationPropertyCollection propertys = new ConfigurationPropertyCollection();
                        new ConfigurationProperty(
                            UnitySectionNameAttributeName, typeof(String), String.Empty, null, null, ConfigurationPropertyOptions.None));
                        new ConfigurationProperty(
                            UnityContainerNameAttributeName, typeof(String), String.Empty, null, null, ConfigurationPropertyOptions.None));
                    _properties = propertys;
                return _properties;

The configuration to hook this behavior up to a service looks like this.

<?xml version="1.0" ?>
        <section name="customUnitySection"
                    type="Microsoft.Practices.Unity.Configuration.UnityConfigurationSection, Microsoft.Practices.Unity.Configuration"/>
            <container name="customContainer">
                <register type="Neovolve.Toolkit.Unity.WebIntegrationTests.TestService, Neovolve.Toolkit.Unity.WebIntegrationTests">
                        <param name="prefix">
                            <value value="Injected by custom unity section and container"/>
                <behavior name="UnityBehavior">
                    <unityService unitySectionName="customUnitySection"
                <add name="unityService"
                        type="Neovolve.Toolkit.Unity.UnityServiceElement, Neovolve.Toolkit.Unity, Version=, Culture=neutral, PublicKeyToken=911824a9aa319cb2"/>
            <service behaviorConfiguration="UnityBehavior"
                <endpoint address=""

The configuration for the element shown here allows for defining custom configuration section and container names for resolving the Unity container.

ServiceHostFactory or configured service behavior

Which one to use?

If you have multiple containers, or a single container that must have a name, then you have no choice but to use the service behavior element as outlined in this post. The only other reason for using the behavior element is if you must use another type of custom factory (such as the WIF WSTrustServiceHostFactory). There really should be no reason to use a non-standard configuration section name for Unity so I don’t think that is a big factor.

Using the ServiceHostFactory is the preferred option as it will result in a slightly cleaner configuration if you are not forced into using a configured service behavior,

The code with xml comments can be found in my Toolkit project on CodePlex.