Contextual logger injection for Autofac

TL;DR: install package AutofacSerilogIntegration, call builder.RegisterLogger(), and use constructor injection of ILogger to get source type tagging.

When I use Serilog, I more often than not embrace the static Log class and use a pattern like:

class Example
    readonly ILogger _log = Log.ForContext<Example>();

    public void Show()

Notice in this example the ForContext<Example>() call. This creates a contextual logger that will tag all of the events created through it with the name of the specified class, in this case Example. Serilog does this by attaching a property called SourceContext.

SourceContext can be very useful for filtering. Here, using the Seq sink, we can see all events raised by PreadmissionController:


Logger Injection

When using an IoC container like Autofac, it’s quite common to inject a logger into the class using it. In this case our example would follow a slightly different pattern:

class Example
    readonly ILogger _log;

    public Example(ILogger log)
        _log = log;

    public void Show()

Here, instead of calling ForContext<Example>(), the expectation is that the appropriate logger will be passed into the constructor by the caller.

Though I’ve tended to move away from this pattern in recent years (if for nothing else, just to cut down the number of parameters on constructors!) I’ve encountered lots of codebases that use this tactic and find it works well.

Unfortunately, despite founding both the Autofac and Serilog projects, when asked how to set this up I’ve had to point people to Google and newsgroup posts, and don’t think there’s been a comprehensive example online showing how it can work efficiently and reliably. So, finally, I’ve posted a working integration on GitHub and published it as the AutofacSerilogIntegration NuGet package. Here’s how it’s used.

Setting up the Autofac/Serilog Integration

As with all good stories, this one begins at the NuGet package manager command-line:

Install-Package AutofacSerilogIntegration

(This assumes you’ve installed both the Autofac and Serilog packages already.)

The first thing you should do in your application is configure a logger. I recommend assigning this to Log.Logger even if you don’t intend to use the static Log class, just in case any calls to the static logger slip in accidentally.

Log.Logger = new LoggerConfiguration()

Next up, where your Autofac ContainerBuilder is configured, call RegisterLogger(). This is an extension method in the AutofacSerilogIntegration namespace..

var builder = new ContainerBuilder();

And, that’s everything. For components created by the container, parameters of type ILogger will now be fulfilled using a logger instance tagged with the correct type.

The RegisterLogger() method accepts a couple of parameters – an ILogger can be specified if you want to use a root logger separate from the static one, and property injection can be optionally enabled.

Closing thoughts…

This is a shiny new slice of code and there may still be scenarios it doesn’t handle so well. The beauty of getting it to GitHub is that over time it can be improved through use – pull requests appreciated! I hope it saves you some searching next time you hit File > New Project.

Autofac update 2.6.1 published

The eagle-eyed may have already spotted Autofac 2.6.1 lurking in the NuGet feed.

The last release, the venerable 2.5.2, served us very well (maturity is a feature!) and this release adds a little more polish, without any known breaking changes.

  • The ASP.NET MVC integration package gets a bug fix for recursive views, UrlHelper and RequestContext registered by AutofacWebTypesModule, and an explicit method for registering model binders.
  • The WCF integration package gets much improved support for services with InstanceContextMode.Single.
  • A new helper InstancePerOwned<T>() makes it easier to control lifetime when using Owned<T>.
  • Autofac can now be used with .NET Portable Class Libraries (download only on the project site. (The Windows Phone 7 build now uses this configuration too.)
  • Autofac.dll is now clear of any issues found by SecAnnotate.exe.

Extra thanks to Alex and Travis for the majority of these improvements.

Autofac 2.5 Released

Autofac 2.5 is now available on the project site and via NuGet. The new version includes a range of great contributions.

After incubation as an external project, Windows Phone 7 now joins ranks of officially-supported targets (just install the Autofac package via NuGet and you’re up and running!) For some tips on getting started see Brendan Kowitz’s notes.

The new release is highly-compatible with Autofac 2.4 (best used with the VS2010 compiler when targeting .NET 3.5.)

Included changes are:

  • Issue 329 – types are filtered by compatibilty before invoking key mapping functions when scanning assemblies
  • RegisterAssemblyTypes(...).WithMetadataFrom<T>() simplifies extraction of metadata from attribute properties
  • Module.ThisAssembly simplifies implementation of modules that scan their own assembly
  • Issue 333 – enable RegisterAssemblyTypes(...).PreserveExistingDefaults()
  • Windows Phone 7 and 7.1 support
  • Issue 312 – allow ContainerBuilder.Update() on the ComponentRegistry of any
    ILifetimeScope without affecting the parent scope
  • Issue 327 – allow autowiring of enum properties
  • Issue 319 – support list and dictionary literals in XML configuration
  • Issue 330 – corrections to generic type constraint checking where the constraint type is an interface
  • Issue 331 – fix build warnings and runtime issues using Moq integration
  • Introduced ContainerBuildOptions to control invocation of IStartable.Start() under unit tests
  • Container.Empty is now a property rather than a field (protection from inadvertent updates
  • Removed broken/obsolete examples from source tree (better examples are available elsewhere online)
  • Host configuration features for AutofacHostFactory in WCF integration
  • ComponentRegistry.Register() is now safe for use under multiple threads
  • Issue 227 – breaking change additional options (and enum rather than boolean parameter) for PropertiesAutowired()
  • Additional web abstractions are now registered by the MVC3 AutofacWebTypesModule
  • Issue 311 – fixed potential lifetime issues when injecting into MVC filter attributes
  • Tightened up behavior when correct constructor to use under reflection activator is ambiguous (now throws rather than choosing nondeterministically)
  • Issue 309 – fixed some issues in TypeExtensions.IsClosedTypeOf()
  • Improved exception messages

Many thanks to the Autofac project team and collaborators across the web for making this release happen!

Autofac 2.4.5 Release

More than a month has passed since the last patch release of Autofac 2.4, and enough has changed in trunk to warrant a new one. You can download Autofac 2.4.5 from the project site, or preferably, update your NuGet packages within Visual Studio.

In this release you’ll find:

  • Several bug fixes and improved exception messages
  • Travis and Alex have been busy making the Multi-tenant contrib package work better with the new ASP.NET MVC3 integration
  • The awkward but very useful IContainerAwareComponent introduced in 2.4 has been deprecated and morphed into a much friendlier and more useful Startable implementation
  • Autofac now consistently throws DependencyResolutionException (or a subclass) whenever fatal errors occur during composition

Please feel free to drop in and share your experiences on the discussion forum. For help with using Autofac, including new features, the preferred medium is Stack Overflow.

Autofac 2.4 is here – come and “NuGet” it!

The latest release of the Autofac IoC container is now available on the project site and via NuGet.

ASP.NET MVC Integration Changes

The best thing in the new release, and possibly since sliced bread, is the new Autofac ASP.NET MVC integration. Gone are special interfaces on HttpApplication, gone are the Web.config file edits, static properties in the application class and multiple different extension points to configure. It couldn’t get any simpler than this.

Here’s how you create a new Autofac-enabled ASP.NET MVC3 project:

1. Create a new MVC3 web application

2. Install the Autofac.Mvc3 Package

3. Set up the Container and DependencyResolver

protected void Application_Start()
    var builder = new ContainerBuilder();
    var container = builder.Build();
    DependencyResolver.SetResolver(new AutofacDependencyResolver(container));

    // Other MVC setup...

That’s it!

That’s all you need to do to enable dependency injection into your controllers. There’s a lot more you can do with Autofac and ASP.NET MVC3 – I highly recommend checking out some of Alex’s recent posts on the subject.

The Autofac ASP.NET MVC integration now targets ASP.NET MVC version 3 exclusively. Don’t worry if you’re unable to move to MVC3 right away, see the “Using Autofac 2.4 with ASP.NET MVC2” below.

Complete NuGet Packages

With Autofac 2.4, the recommended way to add Autofac and its sub-features to your applications is to use the NuGet package manager. You can see some of the available packages in the screen shot at step 2 above. Just search for “Autofac” and you’re away.

In the previous Autofac NuGet package, we included the MEF and WCF integrations by default. To keep clutter away, these are now in their own packages Autofac.Mef and Autofac.Wcf respectively.

Improved Decorator Support

The new and improved decorator support makes it much easier to wire up generic decorators with Autofac, and also provides a nice boost when using decorators in other scenarios.

Removed Older Silverlight Versions from Supported Builds

To keep the maintenance burden of the project as light as practical, it is occasionally necessary to discontinue ‘official’ support for older framework versions. In Autofac 2.4, the Silverlight 3 configuration is no longer available. Users of Silverlight 3 should continue to run the Autofac 2.3 builds (bug fixes will be provided for these whenever necessary.)

Events and Interfaces to Support Tracing

Like all IoC containers, Autofac’s internals can be somewhat opaque to follow at runtime. For the occasions that diagnostics are necessary, Autofac 2.4 supports more events that can be used to trace the operations of the container. As an example, ILifetimeScope now supports LifetimeScopeBeginning, ResolveOperationBeginning and other related extension points.

It is intended that these will be used more by Autofac integration and tooling developers than in general application development.

Other Release Notes

The community has been busy as usual, and you’ll find quite a few other enhancements in this release.

  • .AsImplementedInterfaces() is now supported on non-scanning registrations
  • IDisposable is no longer considered a service by .AsImplementedInterfaces()
  • Additional eager checks for generic type/service compatibility at registration time
  • An additional .WithParameter() overload has been added, accepting predicate and value accessor like ResolvedParameter
  • Extension methods for common predicates on System.Type are now public for use with scanning, e.g. Except(t => t.IsClosedTypeOf(x))
  • MVC ExtensibleActionInvoker does not inject action method parameters by default
  • ILifetimeScope rather than IContainer is now accepted by ServiceHostBase (WCF integration)
  • AutofacInstanceContext has been made public so that current scope can be retrieved when needed (WCF integration)
  • Bug fixes and enhancements in AutofacContrib.Multitenant and AutofacContrib.Attributed
  • Dependencies upgraded e.g. Castle Core and NHibernate
  • Fixed bug #288 – resolve all failing in customised lifetime scopes when one component supports multiple interfaces

Using Autofac 2.4 with ASP.NET MVC2

If you’re still using ASP.NET MVC2 in your application, the simplest course of action is to continue using the Autofac 2.3 release series and the appropriate integration bundled with that, until you’re able to upgrade wholesale to ASP.NET MVC3.

If you would like to use Autofac 2.4 with ASP.NET MVC, there is an updated Autofac.Mvc2 NuGet package now on the feed. If you’re already using the MVC2 NuGet package, update the package and you should be fine. If not, first remove all Autofac*.dll references from your project and then install the Autofac.Mvc2 package using the “Add Library Reference” dialog.

Edit: You need to add assembly binding redirects in order for the MVC2 package to work. The appropriate redirects are specified below (you may need to update them with the current Autofac version number) or you can use the commands bundled with NuGet.

  <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <assemblyIdentity name="Autofac" publicKeyToken="17863af14b0044da" />
      <bindingRedirect oldVersion="" newVersion="" />
      <assemblyIdentity name="Autofac.Integration.Web" publicKeyToken="17863af14b0044da" />
      <bindingRedirect oldVersion="" newVersion="" />

Summing Up

I hope that with this release, Autofac is now easier to get and set up than ever before. It has once again been a team effort – thanks especially to the contributors and everyone who has submitted issue reports or patches.

An Autofac Lifetime Primer

Or, “Avoiding Memory Leaks in Managed Composition”

Understanding lifetime can be pretty tough when you’re new to IoC. Even long-time users express vague fears and misgivings when it comes to this subject, and disconcerting issues – components not being disposed, steadily climbing memory usage or an OutOfMemoryException – have bitten many of us at one time or another.

Avoiding lifetime issues when using an IoC container is generally straightforward, but doing so successfully is more a question of application design rather than just container API usage. There’s lots of good advice out there, but very little of it tells the complete story from beginning to end. I’ve attempted to do that with this rather long article, and hope that with a bit of feedback from you it can be shaped into a useful reference.

This article is about Autofac, but the broad issues are universal – even if you’re not an Autofac user, chances are there’s something to learn about your container of choice.

What Leaks?

Let’s begin with the issue that in all likelihood brought you here. Tracking containers like Autofac hold references to the disposable components they create.

By disposable we mean any component that implements the BCL’s IDisposable interface (or is configured with an OnRelease() action):

interface IMyResource {}

class MyResource : IMyResource, IDisposable {}

When an instance of MyResource is created in an Autofac container, the container will hold a reference to it even when it is no longer being used by the rest of the program. This means that the garbage collector will be unable to reclaim the memory held by that component, so the following program will eventually exhaust all available memory and crash:

var builder = new ContainerBuilder();
using (var container = builder.Build())
    while (true)
        var r = container.Resolve<IMyResource>(); // Out of memory!

This is a far cry from typical CLR behaviour, which is one more reason why it is good to get away from thinking about an IoC container as a replacement for new. If we’d just created MyResource directly in the loop, there wouldn’t be any problem at all:

while (true)
    var r = new MyResource(); // Fine, feed the GC

Transitive Dependencies

Looking at the code above you might be tempted to think that the problem only surfaces when disposable components are resolved directly from the container. That’s not really the case – every disposable component created by the container is tracked, even those created indirectly to satisfy dependencies.

interface IMyService { }

class MyComponent : IMyService
    // Dependency on a service provided by a disposable component
    public MyComponent(IMyResource resource) {}

If a second component is resolved that depends on a service provided by a disposable component, the memory leak still occurs:

while (true)
    // Still holds instances of MyResource
    var s = container.Resolve<IMyService>();

Results Returned from Delegate Factories

Rather than calling Resolve() directly on an IContainer we might instead take a dependency on an Autofac delegate factory type like Func<T>:

interface IMyService2
    void Go();

class MyComponent2 : IMyService2
    Func<IMyResource> _resourceFactory;

    public MyComponent(Func<IMyResource> resourceFactory)
        _resourceFactory = resourceFactory;

    public void Go()
        while (true)
            var r = _resourceFactory(); // Still out of memory.

Now in the main loop we only resolve one component instance and call the Go() method.

using (var container = builder.Build())
    var s = container.Resolve<IMyService2>();

Even though we’ve only called the container once directly, the leak is still there.

Why does Autofac behave this way?

It might seem that there are several traps here, though there’s really only one – and it is worth reiterating:

Autofac will track every disposable component instance that it creates, no matter how that instance is requested.

This isn’t, of course, the end of the road. Autofac is very carefully designed to make resource management easier than programming without a container. Notice I slipped in the word resource there? The ‘memory leaks’ we’re talking about are a result of preventing another kind of ‘leak’ – the resources that are managed through IDisposable.

What are Resources?

Traditionally, a resource might be defined as anything with finite capacity that must be shared between its users.

In the context of components in an IoC container, a resource is anything with acquisition and release phases in its lifecycle. Many low-level examples exist, such as components that rely on items from the list below, but it is also very common to find high-level application constructs with similar semantics.

  • Locks (e.g. Monitor.Enter() and Monitor.Exit())
  • Transactions (Begin and Commit/Abort)
  • Event subscriptions (+= and -=)
  • Timers (Start and Dispose)
  • Machine resources like sockets and files (usually Open/Create and Close)
  • Waiting worker threads (Create and Signal)

In .NET there’s a standard way to represent resource semantics on a component by implementing IDisposable. When such a component is no longer required, the Dispose() method must be called to complete the ‘release’ phase.

Not Calling Dispose() is most often a Bug

You can read some interesting discussions via Kim Hamilton’s and Joe Duffy’s articles on the topic of when Dispose() must be called.

There’s a fairly strong consensus that more often than not, failing to call Dispose() will lead to a bug, regardless of whether or not the resource in question is protected by a finalizer (or SafeHandle).

What is less clear is how applications and APIs should be structured so that Dispose() can be called reliably and at the correct time.

IDisposable and Ownership

Before IoC (assuming you use it now) there were probably two approaches you could apply to calling Dispose():

  1. The C# using statement
  2. Ad-hoc

IDisposable and using are a match made in heaven, but they only apply when a resource’s lifetime is within a single method call.

For everything else, you need to find a strategy to ensure resources are disposed when they’re no longer required. The most widely-attempted one is based around the idea that whatever object acquires the resource should also release it. I pejoratively call it “ad-hoc” because it doesn’t work consistently. Eventually you’ll come up against one (and likely more) of the following issues:

Sharing: When multiple independent components share a resource, it is very hard to figure out when none of them requires it any more. Either a third party will have to know about all of the potential users of the resource, or the users will have to collaborate. Either way, things get hard fast.

Cascading Changes: Let’s say we have three components – A uses B which uses C. If no resources are involved, then no thought needs to be given to how resource ownership or release works. But, if the application changes so that C must now own a disposable resource, then both A and B will probably have to change to signal appropriately (via disposal) when that resource is no longer needed. The more components involved, the nastier this one is to unravel.

Contract vs. Implementation: In .NET we’re encouraged to program to a contract, not an implementation. Well-designed APIs don’t usually give details of the implementation type, for example an Abstract Factory could be employed to create caches of different sizes:

public ICache CreateCache(int maximumByteSize);  // Abstract Factory

interface ICache // : IDisposable?
    void Add(object key, object value, TimeSpan ttl);
    bool TryLookup(object key, out object value);

The initial implementation may return only MemoryCache objects, that have no resource management requirements. However, because we may in future create a FileCache implementation, does that mean that ICache should be disposable?

The root of the problem here is that for any contract, it is conceivable that there will one day be an implementation that is disposable.

This particular problem is exacerbated by loosely-coupled systems like those built with IoC. Since components only know about each other through contracts (services) and never their implementation types, there really isn’t any way for one component to determine whether it should try to dispose another.

IoC to the Rescue!

There is a viable solution out there. As you can guess, a) in typical enterprise and web applications and b) at a certain level of granularity IoC containers provide a good solution to the resource management problem.

To do this, they need to take ownership of the disposable components that they create.

But this is only part of the story – they also need to be told about the units of work that the application performs. This is how the container will know to dispose components and release references, avoiding the memory leak problems that will otherwise occur.

Why not have the container use WeakReference just to be safe? A solution that relies on WeakReference is afflicted by the same problems as not calling Dispose() at all. Allowing components to be garbage collected before the enclosing unit of work is complete can lead to a whole class of subtle load- and environment-dependent bugs. Many higher-level resources are also unable to be properly released within a finalizer.

Units of Work

As they run, enterprise and web applications tend to perform tasks with a defined beginning and end. These tasks might be things like responding to a web request, handling an incoming message, or running a batch process over some data.

These are tasks in the abstract sense – not to be confused with something like Task<T> or any of the asynchronous programming constructs. To make this clearer, we’ll co-opt the term ‘unit of work’ to describe this kind of task.

Determining where units of work begin and end is the key to using Autofac effectively in an application.

Lifetime Scopes: Implementing Units of Work with Autofac

Autofac caters to units of work through lifetime scopes. A lifetime scope (ILifetimeScope) is just what it sounds like – a scope at the completion of which, the lifetime of a set of related components will end.

Component instances that are resolved during the processing of a unit of work get associated with a lifetime scope. By tracking instantiation order and ensuring that dependencies can only be satisfied by components in the same or a longer-lived lifetime scope, Autofac can take responsibility for disposal when the lifetime scope ends.

Going back to our original trivial example, the leak we observed can be eliminated by creating and disposing a new lifetime scope each time we go through the loop:

// var container = …
while (true)
    using (var lifetimeScope = container.BeginLifetimeScope())
        var r = lifetimeScope.Resolve<IMyResource>();
        // r, all of its dependencies and any other components
        // created indirectly will be released here

This is all it takes to avoid memory and resources leaks with Autofac.

Don’t resolve from the root container. Always resolve from and then release a lifetime scope.

Lifetime scopes are extremely flexible and can be applied to a huge range of scenarios. There are a few handy things to know that might not be immediately obvious.

Lifetime Scopes can Exist Simultaneously

Many lifetime scopes can exist simultaneously on the same container. This is how incoming HTTP requests are handled in the Autofac ASP.NET integration, for example. Each request causes the creation of a new lifetime scope for handling it; this gets disposed at the end of the request.

Note that we call the root of the lifetime scope hierarchy the ‘Application’ scope, because it will live for the duration of an application run.

Lifetime Scopes can be Nested

The container itself is the root lifetime scope in an Autofac application. When a lifetime scope is created from it, this sets up a parent-child relationship between the nested scope and the container.

When dependencies are resolved, Autofac first attempts to satisfy the dependency with a component instance in the scope in which the request was made. In the diagram below, this means that the dependency on an NHibernate session is satisfied within the scope of the HTTP request and the session will therefore be disposed when the HTTP request scope ends.

When the dependency resolution process hits a component that cannot be resolved in the current scope – for example, a component configured as a Singleton using SingleInstance(), Autofac looks to the parent scope to see if the dependency can be resolved there.

When the resolve operation has moved from a child scope to the parent, any further dependencies will be resolved in the parent scope. If the SingleInstance() component Log depends on LogFile then the log file dependency will be associated with the root scope, so that even when the current HTTP request scope ends, the file component will live on with the log that depends on it.

Lifetime scopes can be nested to arbitrary depth:

var ls1 = container.BeginLifetimeScope();
var ls2 = ls1.BeginLifetimeScope();
// ls1 is a child of the container, ls2 is a child of ls1

Sharing is driven by Lifetime Scopes

At this point in our discussion of lifetime management (you thought we were going to talk about memory leaks but that’s just how I roped you in!) it is worth mentioning the relationship between lifetime scopes and how Autofac implements ‘sharing’.

By default, every time an instance of a component is needed (either requested directly with the Resolve() method or as a dependency of another component) Autofac will create a new instance and, if it is disposable, attach it to the current lifetime scope. All IoC containers that I know of support something like this kind of ‘transient lifestyle’ or ‘instance per dependency.’

Also universally supported is ‘singleton’ or ‘single instance’ sharing, in which the same instance is used to satisfy all requests. In Autofac, SingleInstance() sharing will associate an instance with the root node in the tree of active lifetime scopes, i.e. the container.

There are two other common sharing modes that are used with Autofac.

Matching Scope Sharing

When creating a scope, it is possible to give it a name in the form of a ‘tag’:

// For each session concurrently managed by the application
var sessionScope = container.BeginLifetimeScope("session");

// For each message received in the session:
var messageScope = sessionScope.BeginLifetimeScope("message");
var dispatcher = messageScope.Resolve<IMessageDispatcher>();

Tags name the levels in the lifetime scope hierarchy, and they can be used when registering components in order to determine how instances are shared.


In this scenario, when processing messages in a session, even though we always Resolve() dependencies from the messageScopes, all components will share a single CredentialCache at the session level.

Current Scope Sharing

While occasionally units of work are nested multiple layers deep, most of the time a single executable will deal with only one kind of unit of work.

In a web application, the ‘child’ scopes created from the root are for each HTTP request and might be tagged with "httpRequest". In a back-end process, we may also have a two-level scope hierarchy, but the child scopes may be per-"workItem".

Many kinds of components, for example those related to persistence or caching, need to be shared per unit of work, regardless of which application model the component is being used in. For these kinds of components, Autofac provides the InstancePerLifetimeScope() sharing model.

If a component is configured to use an InstancePerLifetimeScope() then at most a single instance of that component will be shared between all other components with the same lifetime, regardless of the level or tag associated with the scope they’re in. This is great for reusing components and configuration between different applications or services in the same solution.

Lifetime Scopes don’t have any Context Dependency

It is completely acceptable to create multiple independent lifetime scopes on the same thread:

var ls1 = container.BeginLifetimeScope();
var ls2 = container.BeginLifetimeScope();
// ls1 and ls2 are completely independent of each other

It is also perfectly safe to share a single lifetime scope between many threads, and to end a lifetime scope on a thread other than the one that began it.

Lifetime scopes don’t rely on thread-local storage or global state like the HTTP context in order to do their work.

Components can Create Lifetime Scopes

The container can be used directly for creating lifetime scopes, but most of the time you won’t want to use a global container variable for this.

All a component needs to do to create and use lifetime scopes is to take a dependency on the ILifetimeScope interface:

class MessageDispatcher : IMessageDispatcher
    ILifetimeScope _lifetimeScope;

    public MessageDispatcher(ILifetimeScope lifetimeScope)
        _lifetimeScope = lifetimeScope;

    public void OnMessage(object message)
        using (var messageScope = _lifetimeScope.BeginLifetimeScope())
            var handler = messageScope.Resolve<IMessageHandler>();

The ILifetimeScope instance that is injected will be the one in which the component ‘lives.’

Owned Instances

Owned instances (Owned<T>) are the last tale in Autofac’s lifetime story.

An owned instance is a component that comes wrapped in its own lifetime scope. This makes it easier to keep track of how a component should be released, especially if it is used outside of a using statement.

To get an owned instance providing service T, you can resolve one directly from the container:

var ownedService = container.Resolve<Owned<IMyService>>();

In lifetime terms, this is equivalent to creating a new lifetime scope from the container, and resolving IMyService from that. The only difference is that the IMyService and the lifetime scope that holds it come wrapped up together in a single object.

The service implementation is available through the Value property:

// Value is IMyService

When the owned instance is no longer needed, it and all of its disposable dependencies can be released by disposing the Owned<T> object:


Combining with Func Factories

Autofac automatically provides Func<T> as a service when T is registered. As we saw in an earlier example, components can use this mechanism to create instances of other components on the fly.

class MyComponent2 : IMyService2
    Func<IMyResource> _resourceFactory;

    public MyComponent(Func<IMyResource> resourceFactory)
        _resourceFactory = resourceFactory;

    public void Go()
        while (true)
            var r = _resourceFactory(); // Out of memory.

Components that are returned from Func<T> delegates are associated with the same lifetime scope as the delegate itself. If that component is itself contained in a lifetime scope, and it creates a finite number of instances through the delegate, then there’s no problem – everything will be cleaned up when the scope completes.

If the component calling the delegate is a long-lived one, then the instances returned from the delegate will need to be cleaned up eagerly. To do this, Owned<T> can be used as the return value of a factory delegate:

class MyComponent2 : IMyService2
    Func<Owned<IMyResource>> _resourceFactory;

    public MyComponent(Func<Owned<IMyResource>> resourceFactory)
        _resourceFactory = resourceFactory;

    public void Go()
        while (true)
            using (var r = _resourceFactory())
                // Use r.Value before disposing it

Func<T> and Owned<T> can be combined with other relationship types to define relationships with a clearer intent than just taking a dependency on ILifetimeScope.

Do I really have to think about all this stuff?

That concludes our tour of lifetime management with Autofac. Whether you use an IoC container or not, and whether you use Autofac or another IoC container, non-trivial applications have to deal with the kinds of issues we’ve discussed.

Once you’ve wrapped your mind around a few key concepts, you’ll find that lifetime rarely causes any headaches. On the plus side, a huge range of difficult application design problems around resource management and ownership will disappear.

Just remember:

  1. Autofac holds references to all the disposable components it creates
  2. To prevent memory and resource leaks, always resolve components from lifetime scopes and dispose the scope at the conclusion of a task
  3. Effectively using lifetime scopes requires that you clearly map out the unit of work structure of your applications
  4. Owned instances provide an abstraction over lifetime scopes that can be cleaner to work with

Happy programming!


Decorator Support in Autofac 2.4

Autofac 2.4 is just around the corner, with beta builds now available via the project site (the short list of changes since 2.3 is available here.) One of the enhancements coming with this release is improved support for wiring up components in the Decorator Pattern.

Circa Autofac 2.2 we introduced container support for the Adapter Pattern. An Adapter takes a service and exposes its functionality through a different interface. While it has always been possible to implement adapters in Autofac using the basic APIs, adding container support for “bottom-up” composition makes it easier to implement adaptation reliably on all implementations of an adapted service.

Decorators are a similar story. Given an implementation of a service, a decorator takes that implementation and modifies its functionality, exposing the same interface.

interface ICommandHandler { }

class CommandHandler : ICommandHandler { }

class TransactedCommandHandler : ICommandHandler {
    public TransactedCommandHandler(
        ICommandHandler decorated,
        ISession session) { }

Here the TransactedCommandHandler is a decorator for the ICommandHandler service, that adds transaction management via a persistence session. The CommandHandler component provides the actual implementation of the service.

Decorator structure

Decorator structure

Decorators by Hand

In Autofac the components for this scenario can be registered without any special decorator support:

var builder = new ContainerBuilder();


builder.Register(c => new TransactedCommandHandler(

This takes advantage of a named service to identify the implementor, and thus link it up to its decorator which is registered to provide the service type (not named.)

Clean and straightforward – and recommended if your scenario is as simple as the one above. If you have more than one component that you’d like decorated, or want to use decorators with open generics, then things can get more complicated rather quickly.

Drawing on a lot of inspiration from the design philosophy of MEF, Autofac has good support for handling n things like this. In 2.4, we use that support to automate some of the process of configuring decorators.

IoC Design Tip: When you’re looking for abstractions to use as services in an application, prefer those that describe a set of related things. Zero-or-more type relationships are less brittle in the face of change than exactly one or zero-or-one relationships.

RegisterDecorator() and RegisterGenericDecorator()

There are two new registration methods for decorators in Autofac 2.4 – a non-generic and a generic version.

The non-generic version, when applied to the scenario above, looks like:

var builder = new ContainerBuilder();


        (c, inner) => new TransactedCommandHandler(inner, c.Resolve<ISession>()),
        fromKey: "implementor");

The first thing you’re probably thinking is “hey, this isn’t any less code than the old way!” That’s very likely true, but reducing the amount of code involved wasn’t a goal here.

The difference between this code, using RegisterDecorator and the first example is that this version decorates all implementations of ICommandHandler, so if additional command handlers are registered (using the “implementor” name) then they will each get their own decorator.

There are some diagrams in the adapter article previously linked that describe the object graph structure; reading that article will shed some light on what I’m talking about here if the details are a bit foggy.

RegisterDecorator() works a lot like Autofac’s typical delegate-based component registration methods. The things to note are:

  • The generic parameter (here ICommandHandler) is the service that is being decorated.
  • The method accepts a delegate that, given the context c and the implementation of the service being decorated inner, produces an instance of the decorator.
  • The final pair of parameters are fromKey and toKey (optional) that describe where this decorator sits in the chain from implementation up to the topmost decorator. This works the same way as in the decoration-by-hand example earlier.

RegisterGenericDecorator() is similar to its non-generic counterpart, but deals with cases where the decorated service is an open generic one. Given a generic alternative to the earlier example:

interface ICommandHandler<TCommand> { }

class CommandHandler<TCommand> : ICommandHandler<TCommand> { }

class TransactedCommandHandler<TCommand> : ICommandHandler<TCommand> {
    public TransactedCommandHandler(
        ICommandHandler<TCommand> decorated,
        ISession session) { }

Setting up the same decorator structure is done using:

var builder = new ContainerBuilder();

    .Named("implementor", typeof(ICommandHandler<>));

        fromKey: "implementor");

It is worth noting that while the decorator is an open generic type, the decorated components don’t have to be. So, if there are concrete command handler types:


The generic decorator will be applied to each concrete implementation as expected.

There are other ways of implementing decorator support and different choices that can be made about how the APIs should work. There are certainly some big trade-offs made in this implementation; in most of them, simplicity and orthogonality trumped concision or ‘magic.’ A discussion of these decisions almost made it into this article, but I worried about this obscuring the more useful and concrete content. If you have any questions about why things are done this way please do post a comment!

Autofac Project Status Update

Autofac 2.4 Coming Soon

Sometime early in the New Year we’ll be releasing a new version of Autofac.

The star of the show in Autofac 2.4 is a much revamped ASP.NET MVC implementation by Alex Meyer-Gleaves, optimised for use with the MVC3 release. This promises a much quicker, simpler and more robust setup process, finally ridding us of the dependency on an HTTP module (Web.config change) for lifetime control.

Also included in Autofac 2.4 is support for decorators, including some pretty sophisticated coverage of open generic decorator scenarios. In earlier versions of Autofac the very useful Decorator pattern could be a little awkward to implement – I’ll be writing more soon about how Autofac 2.4 tidies this up.

Finally, the new release will continue our recent efforts to improve error messages and bring more consistency and completeness to the APIs introduced in the 2.x series, such as the assembly scanning support. There are no planned breaking changes.

NuGet Packages

Through distribution with ASP.NET MVC3, the NuGet package manager is rapidly gaining traction as the standard way to distribute open source projects for .NET. Thanks to the pioneering efforts of some of the Autofac community there are packages for:

  • Autofac, including its WCF and MEF integrations, for .NET 3.5/4.0 and Silverlight 3/4 (Autofac)
  • Autofac with ASP.NET MVC2 for .NET 3.5/4.0 (Autofac.Mvc2)
  • Autofac with ASP.NET WebForms for .NET 3.5/4.0 (Autofac.Web)

While we expect to fine tune the packages along with the upcoming 2.4 release, you can certainly use NuGet today if you want to use Autofac in your projects.

Open Generics and Autofac 2.3

Autofac 2.3 hit the shelves more than three months ago but as it coincided pretty closely with the birth of our daughter Vera I didn’t write much about it at the time.

One improvement worth mentioning is the much-expanded support for open generic components, contributed by Rikard Pavelic. I answered a recent question on the Autofac mailing list with “it can’t be done” only to find later that the scenario being discussed was already supported. Though fairly unusual, it is an interesting feature so I’ll describe it below, but first the less exotic cases.

Generic Parameter Constraints

C# allows the arguments of a generic type to apply constraints that parameters must match. For example, we might constrain an event handler implementation to a type of event:

interface IEventHandler<in TEvent> {
    void Handle(TEvent @event);

In this small example we have an interface that helps us dispatch event objects to handlers. Typically there would be one or more handlers for each event type, most of them specific to the kind of event. We also have a marker interface for events that should trigger some kind of auditing, and a handler that will make this happen.

interface IAuditableEvent { }

class AuditingEventHandler<TEvent> : IEventHandler<TEvent>
        where TEvent : IAuditableEvent {
    void Handle(TEvent @event) {
       // Write an audit record…

Note that the handler uses a generic type constraint to select the kind of events it is interested in. Some events will be auditable, others not:

class ItemAddedToCartEvent { }

class CheckoutCompletedEvent : IAuditableEvent { }

The AuditingEventHandler<TEvent> will be registered as an open generic type.

var builder = new ContainerBuilder();
var container = builder.Build();

Assuming that we’ve registered all of the different event handlers for the above two events, what should happen when we resolve all of the handlers for ItemAddedToCartEvent?

var handlers = container.Resolve<IEnumerable<IEventHandler<ItemAddedToCartEvent>>>();

The AuditingEventHandler<TEvent> component is registered to provide the IEventHandler<TEvent> service, but the generic type constraint doesn’t match. In earlier versions of Autofac, the above line would have raised an exception.

With support for open generic parameter constraints, Autofac will now instantiate only the types whose constraints match, so the handlers collection above would be returned successfully without any attempt to instantiate the AuditingEventHandler<TEvent>.

If instead an auditable event is to be handled, then the auditing handler would be included:

// Succeeds and returns an AuditingEventHandler<CheckoutCompletedEvent>
var handlers = container.Resolve<IEnumerable<IEventHandler<CheckoutCompletedEvent>>>();

Constraint Types

Autofac 2.3 handles all of the generic parameter constraints you’re likely to encounter, including:

  • new()
  • class and struct
  • Base type and implemented interfaces

Parameter Binding Solver

Open generic types are more subtle and complicated to support than they sometimes appear. Take this contrived but not unimaginable example:

class MonoDictionary<T> : IDictionary<T,T> { }

The generic parameter T appears twice in the parameter list of the implemented IDictionary<TKey,TValue>! That means if we register MonoDictionary<T>:


Then we should be able to resolve IDictionary<int,int> but not IDictionary<int,string>. Tricky – but as of version 2.3, Autofac can handle it.

The example we discussed on the Autofac mailing list was something like:

interface IProducer<T> { }

class NullableProducer<T> : IProducer<T?>
    where T : struct { }

The twist here is that the generic component NullableProducer<T> does not parameterise IProducer<T> directly with T, but rather Nullable<T> (abbreviated to T?).

This means that if we resolve IProducer<int?> then NullableProducer<int> should be activated, while resolving IProducer<int> should ignore NullableProducer<T> altogether.

Autofac 2.3 also supports this case, with some terse but surprisingly succinct code. Hopefully this will open up some new, richer generic component possibilities.

Coming in Autofac 2.3 – OnRelease()

Most components that need to be cleaned up implement IDisposable, which Autofac will use when the component is due to be released. Some components however, notably WCF client proxies, have non-standard ‘release’ behaviour.

There have never been enough cases of these non-standard components to justify messing with the Autofac core model to provide custom release behaviours, so for some time (six major versions, in fact) this hasn’t been added.

Happily, for WCF proxies and other components like them, a simple implementation has been found that allows a custom release action to be piggy-backed on a regular disposable component, so in Autofac 2.3 (currently in preview) we’ll be offering OnRelease() for the first time:

builder.Register(c => CreateWcfClient())
    .OnRelease(client => ReleaseWcfClient(client));

Simple addition – hopefully a pleasant improvement in these scenarios.

For the curious, WCF client proxies require that calls to Dispose() be wrapped in try/catch blocks so that exceptions during disposal don’t obscure any other exceptions thrown during the use of the proxy itself. Not fun stuff, but relax, the Autofac.Integration.Wcf assembly now includes an implementation of UseWcfSafeRelease() as well.