One thing that stuck out in the beginning for the MEF project members with IoC backgrounds, was the verbosity of using [Import] and [Export] attributes to describe parts, instead of the much more terse convention-driven approach used by IoC containers.

Over time, most of us grew to appreciate the role that the attributed programming model played in creating an unambiguous, decentralized configuration mechanism for plug-ins.

What the we also found was that applications using MEF for extensibility would also use it for internal composition, a-la IoC. In the much more controlled context of the host application, the lighter, more direct, convention-driven configuration model is compelling. DRY is one of the most important principles for building maintainable software, so techniques that eliminate repetition are very valuable.

It should be no surprise then, that the latest release of MEF (that I’ve only recently had any involvement in) comes with a nifty little model for defining parts by convention. The syntax should be familiar if you’re used to this kind of API:

When wired up to a MEF catalog, these simple conventions will read a part like:

As:

RegistrationBuilder has more than a few tricks up its sleeve, and we expect to write a lot more about it on the BCL team blog in the coming weeks. For now, you can read about the new release, or even better, download the preview source and binaries from CodePlex.

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!

I think the first session – Fundamentals – is finished. I’m really excited and even a little nervous about putting together a new container on the fly! As a way of bedding down the terminology, mechanics and challenges, I think it is going to be great.

The layout for the remainder of the day still needs work, so I’d better get stuck into it! Those who’ve already signed up, I’ll see you soon – if you haven’t put your name down yet for either Brisbane, Sydney or Melbourne, this is probably the last reminder you’ll get from me.

I spent a fair bit of time yesterday looking at how I can use Whitebox to give an x-ray view of the composition process as the application is built. The information it provides is great – often revealing little issues that would otherwise go unnoticed – but the usability leaves me deeply unsatisfied. Still, it is a start, and by chipping away at it things are improving. Just having a simple view of component details is an improvement:

Today I’m concentrating on the flow of the day. I still have some questions to answer around the introductory session – how theoretical do we want to get? Does it make sense to examine the problems of composition in OO languages, or can we take that as a given for people interested in learning more about IoC? My tendency in the past would have been to go into depth about this, but by starting with “you’re going to use IoC – here’s how to do it” I think the practical side of the Dev Day will be emphasised.

In the end, I went with the idea of a timesheeting application. Simple material keeps out of the way, and to be honest, there is so little logic or fancy presentation in this app that it could be changed from timesheets to another example in a relatively short space of time if need be.

Up and running, we have:

• A basic MVC3 app layout
• IoC set up to create controllers
• Data access with NHibernate
• Transaction management integrated with MVC
• Logging with the venerable log4net
• A skeleton for ‘pick-me-up’ domain events

It is the last item that I’ll be working on in depth today. ‘Pick-me-up’ domain events integrate domain models with external services in a way that plays better with IoC than the thread-static DomainEvents.Raise() pattern commonly seen elsewhere.

Dispatching events to handlers is also a good example of the ‘generic handler’ pattern that’s very widely used, and registering handlers will provide some further examples for convention-based/scanning registration.

To complete the day I’m aiming to polish up the last details of the basic MVC site (for example, error handling) and bed down an example of processing work in a background process to use in the “Resources and Units of Work” session. That leaves tomorrow and Friday for more detailed work on slides, some code samples for the “Containers” session, and some reworking of the example to fit into the flow of the course.

The course is going to be split into four sections, to match the natural division of the day by morning tea, lunch and afternoon tea:

1. Fundamentals
2. Effective IoC
3. Resources and Units of Work
4. Containers and Tooling

Session 1: Fundamentals

First up, we’ll set the theme of the day with some collaborative development. To introduce the vocabulary and concepts of IoC, we’ll write a simple IoC container in C# and integrate it into an ASP.NET MVC application. There are plenty of interesting design issues along the way that we’ll come back to in our discussion of containers and tooling.

Session 2: Effective IoC

The second session will introduce a ‘real’ IoC container. The focus will be on techniques and features that allow IoC to support large, complex applications in the real world. We’ll touch on all of the typical components of MVC web applications as we migrate from the simple container we built ourselves, but we’ll pay special attention to the integration between IoC and domain models because of the challenges and opportunities they present.

Session 3: Resources and Units of Work

Lifetime, AKA “resource management” can be the toughest aspect of IoC to master. We’ll take an excursion outside of the comfort of the web tier, to develop a thorough understanding of the issues involved and their solutions.

Although it is far from being ready for prime time, Whitebox will be a great way to explore the runtime behaviour of lifetime scenarios, so sometime over the coming week I’ll look at filling remaining gaps there.

Session 4: Containers and Tooling

To round out the day, we’ll use the last session to take a leisurely tour of the sights, sounds and smells of the .NET IoC ecosystem. Choosing an IoC container can be tricky business, especially when the easiest metrics to grasp, for example throughput performance, are often misleading or irrelevant. In addition to looking at some of the popular offerings and their relative strengths, I think this is where a discussion of MEF and its role will fit in nicely.

Session 4 will also give us an opportunity to examine debugging and diagnostics issues.

Today

So, what do you think?

Today’s focus for me will be to take a first cut at building the example application. I’m going to leave the ‘simple container’ design task for the event, so that we can truly do it on the fly! I want the day to be heavy on code and light on slides, so dressing up a slide deck with some guiding material will wait for later in the week.

Choosing what kind of application to build is tricky. I want attendees to be able to take something away, ideally a sample that isn’t too far from production readiness. In that respect, simpler will be better, though it can be hard to get enough breadth out of something like a ‘to-do’ or ‘timesheeting’ application. There’s some high-quality code on the web that might be reused for this purpose (e.g. FunnelWeb) so building something that mimics an existing open source application has advantages.

I’ll update you tomorrow on where things land.

I’ve been working with Inversion of Control (IoC) Containers and related technologies since picking up Castle Windsor in 2006, actively developed Autofac for much of that time, and helped shape the first release of the Managed Extensibility Framework. In that period IoC has grown and truly blossomed in the .NET world: from its “enterprise Java” roots we’ve collectively created something that plays to the unique strengths of .NET and C#. Rather than being viewed as an esoteric fringe technology, as it was just a few years ago, IoC is firmly in the .NET mainstream and is increasingly being baked into the platform itself.

Along the way there have been many difficult questions posed, and I’ve had to ask and answer my share. It can be easy to go wrong with IoC – remember the “sharp tools” analogy of the ALT.NET movement? – especially when finding the right approach to IoC in a new situation can mean finding several wrong ways first!

Last year at TechEd Australia I presented a breakout session on IoC in .NET. Though the feedback I received was positive, I was left feeling that an hour was too little time to get many of the concepts across in enough depth. So, this year courtesy of Readify I’m going to be presenting a short course on IoC from the ground, up.

The course will be a full day, with dates in May, 2011 set for:

• Brisbane,
• Sydney and
• Melbourne.

The unifying theme will be ASP.NET MVC, but don’t be discouraged if this is not your primary platform. Much of what we cover will be independent of MVC and even of web programming in general. If you’re unfamiliar with ASP.NET MVC then it might help to brush up on that area if you want to keep up with some of the examples.

In terms of level of technical difficulty, I hope there will be something for everyone. You’ll get the most out of the day if you’re a confident .NET developer with beginner-to-intermediate experience with IoC, or if you’re an experienced user of IoC looking for broader and deeper perspectives on its use.

This week I’m preparing material for the course, and while I have a fair idea of the ground to cover, I’m interested in your ideas. I’ll be posting a progress update each day to keep you informed of where things are heading. I hope in the process I can convince you to come along, and bring your team!

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.

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

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.

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.

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):

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:

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:

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.

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

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>:

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

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:

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:

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:

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’:

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:

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:

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:

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:

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.

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:

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!