autofac / autofac

An addictive .NET IoC container

Autofac is an IoC container for Microsoft .NET. It manages the dependencies between classes so that applications stay easy to change as they grow in size and complexity. This is achieved by treating regular .NET classes as components.

Get Packages

You can get Autofac by grabbing the latest NuGet package. There are several application integration and extended functionality packages to choose from. If you're feeling adventurous, continuous integration builds are on MyGet.

Release notes are available on GitHub.

Get Help

Need help with Autofac? We have a documentation site as well as API documentation. We're ready to answer your questions on Stack Overflow or check out the discussion forum.

Get Started

Our Getting Started tutorial walks you through integrating Autofac with a simple application and gives you some starting points for learning more.

Super-duper quick start:

Register components with a ContainerBuilder and then build the component container.

var builder = new ContainerBuilder();

builder.Register(c => new TaskController(c.Resolve<ITaskRepository>()));
builder.RegisterType<TaskController>();
builder.RegisterInstance(new TaskController());
builder.RegisterAssemblyTypes(controllerAssembly);

var container = builder.Build();

Resolve services from a lifetime scope - either the container or a nested scope:

var taskController = container.Resolve<TaskController>();

There is a growing number of application integration libraries that make using Autofac with your application a snap. Support for several popular frameworks is also available through the "Extras" packages.

Intrigued? Check out our Getting Started walkthrough!

Project

Autofac is licensed under the MIT license, so you can comfortably use it in commercial applications (we still love contributions though).

File issues in the repo with the associated feature/code.

• Autofac - Core dependency resolution and common functions (this repo).
• Autofac.AspNetCore.Multitenant - Multitenant DI support for ASP.NET Core applications.
• Autofac.Configuration - JSON/XML file-based configuration support.
• Autofac.Diagnostics.DotGraph - Diagnostics support to enable DOT graph visualization of resolve requests.
• Autofac.Extensions.DependencyInjection - .NET Core integration for Autofac.
• Autofac.Extras.AggregateService - Dynamic aggregate service implementation generation.
• Autofac.Extras.AttributeMetadata - Metadata scanning/filtering through attributes.
• Autofac.Extras.CommonServiceLocator - Common Service Locator implementation backed by Autofac.
• Autofac.Extras.DynamicProxy - Decorators and interceptors.
• Autofac.Extras.FakeItEasy - FakeItEasy mocking framework integration.
• Autofac.Extras.Moq - Moq mocking framework integration.
• Autofac.Mef - MEF catalog integration.
• Autofac.Multitenant - Multitenant dependency resolution support.
• Autofac.Multitenant.Wcf - Multitenant WCF service hosting.
• Autofac.Mvc - ASP.NET MVC integration.
• Autofac.Mvc.Owin - OWIN support for ASP.NET MVC.
• Autofac.Owin - Core OWIN support - shared middleware for request lifetime integration.
• Autofac.Pooling - Support for pooled instance lifetime scopes.
• Autofac.ServiceFabric - Application integration for Service Fabric services.
• Autofac.SignalR - Application integration for SignalR.
• Autofac.Wcf - WCF service hosting.
• Autofac.Web - ASP.NET web forms integration.
• Autofac.WebApi - Application integration for Web API.
• Autofac.WebApi.Owin - OWIN support for Web API.

Sponsors

Autofac is supported by AWS. Thanks for your contribution!

Contributing / Pull Requests

Refer to the Contributor Guide for setting up and building Autofac source.

You can also open this repository right now in VS Code.

autofac's Issues

Properties injection

From [email protected] on February 29, 2008 22:59:09

Enhancement
The container should do auto injection of properties if he can
It can be an option to set

Original issue: http://code.google.com/p/autofac/issues/detail?id=35

Scope can be specified for provided instances, but only Singleton is appropriate

From [email protected] on November 18, 2007 18:15:41

A runtime error will be generated if a provided instance is registered with
scope other than singleton. Should tighten up builder syntax to make it
harder to do this, especially in in the case of a builder set to default
Factory scope.

Original issue: http://code.google.com/p/autofac/issues/detail?id=11

New events on ContainerBuilder

From [email protected] on February 29, 2008 23:14:40

Enhancement : Important/Urgent (in order to have global behavior like
creating proxy instance for component with special attribut, useful when
implementing a proxy cache/transaction solution)

The ContainerBuilder should expose a global event

Event fired when a new component is registered
.OnRegistered(EventHandler handler)

This will act as a global inspector during component registration

Original issue: http://code.google.com/p/autofac/issues/detail?id=36

Make Id a property of all concrete registrars

From [email protected] on February 25, 2008 20:38:51

Rather than creating and registering unique service names, do this in the
registrar.

Original issue: http://code.google.com/p/autofac/issues/detail?id=33

Add extended properties to XML configuration syntax

From [email protected] on March 13, 2008 21:39:23

I.e. members to be added to the ExtendedProperties dictionary attached to
the component.

Unlike most other configuration file elements, there is no way to determine
the actual concrete type required. In addition to name and value, then, it
is probably a good idea to add an optional type attribute so that
non-string values can be converted.

Original issue: http://code.google.com/p/autofac/issues/detail?id=45

Make ServiceListRegistration subclass ComponentRegistration

From [email protected] on December 04, 2007 19:52:00

The activator for this type needs the list of services that the
registration covers - this will be distinct per context.

Original issue: http://code.google.com/p/autofac/issues/detail?id=13

Create an automatic registration extension

From [email protected] on February 19, 2008 08:13:49

As an alternative to registering components (e.g. controllers) by
enumerating types, provide an automatic predicate-based registrar that at
the fundamental level looks like:

builder.RegisterAutomatically(s => ...).WithScope( InstanceScope .Factory);

...but is built on top of to provide:

builder.RegisterTypeAutomatically(t => ...);

...and possibly even:

builder.RegisterSubclassesAutomatically();

Original issue: http://code.google.com/p/autofac/issues/detail?id=31

Create build script to package components along with integrations

From [email protected] on January 15, 2008 08:53:26

This should be Mono-compatible so that it can be used on a Linux CI server
if necessary.

Original issue: http://code.google.com/p/autofac/issues/detail?id=20

Create .NET 2.0 build of ASP.NET integration

From [email protected] on February 09, 2008 18:56:35

These will still benefit .NET 2.0 users.

Original issue: http://code.google.com/p/autofac/issues/detail?id=26

Create an NHibernate integration facility

From [email protected] on November 11, 2007 17:34:34

A-la the one available for Windsor/Monorail.

Original issue: http://code.google.com/p/autofac/issues/detail?id=6

Enhance IReflectiveRegistrar to support additional constructor selector policies

From [email protected] on March 02, 2008 12:33:05

The core already provides a couple of different constructor selection
policies, it would be handy though if an override of UsingConstructor()
accepted the IConstructorSelector interface.

Original issue: http://code.google.com/p/autofac/issues/detail?id=39

Add Explicit Constructor Selection to XML Configuration API

From [email protected] on November 12, 2007 21:18:21

Namely, support constructor selection, instance scope, instance ownership.

Original issue: http://code.google.com/p/autofac/issues/detail?id=8

Google Code skipped issue 91

Skipping this issue number to maintain synchronization with Google Code issue IDs.

Original issue: http://code.google.com/p/autofac/issues/detail?id=91

Use DynamicMethod or Linq to implement delegate factories

From [email protected] on November 11, 2007 12:14:10

DynamicMethod is a more efficient means of generating factory delegates
than C# compilation. Implementation should replace
InterceptingDelegateActivator.

Original issue: http://code.google.com/p/autofac/issues/detail?id=3

Ideas around immutability

From [email protected] on January 03, 2008 17:46:40

To simplify the implementation of caching it seems like a good idea to make
the typical container implementation immutable (from the perspective of
registrations.)

ContainerBuilder can be used to provide all registrations at construction
time. This will enable aggressive caching of reflection data etc.

There may not be a direct relationship between the mutable and immutable
containers, this needs to be investigated. There may not even be a need for
a mutable version of the container if the use cases can be covered by other
means (e.g. dynamic lambda registrations.)

Will most likely lead to API changes, hence the 2.0 milestone.

Original issue: http://code.google.com/p/autofac/issues/detail?id=19

Mono Test Failures

From [email protected] on December 15, 2007 19:18:01

1. Autofac.Tests.Component.Ownership.DisposerFixture.ReferenceNotHeld :
   Expected: False
   But was: True

at Autofac.Tests.Component.Ownership.DisposerFixture.ReferenceNotHeld ()
[0x00000]
at (wrapper managed-to-native)
System.Reflection.MonoMethod:InternalInvoke (object,object[])
at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags
invokeAttr, System.Reflection.Binder binder, System.Object[] parameters,
System.Globalization.CultureInfo culture) [0x00000]

Original issue: http://code.google.com/p/autofac/issues/detail?id=17

Create a full Tagged Contexts feature

From [email protected] on February 10, 2008 10:58:37

Named Contexts (to be implemented as Tagged Contexts so that, for example,
enumerations rather than strings could be used for tags) control
instantiation in architectures using deeply nested container hierarchies.

This will be one of the first of the 'Autofac Extras' - optional features
deployed separately that extend the container.

Part of this project will be to explore the extensibility mechanisms
already available and how these might be further enhanced so that the core
of Autofac can be kept lean.

Original issue: http://code.google.com/p/autofac/issues/detail?id=28

Implement NMock2 integration

From rinat.abdullin on February 03, 2008 20:27:54

Try out Mocking Container POC for the field testing in xLim 2 and then
extract the best practices into the separate Autofac.Integration.NMock2
project.

Original issue: http://code.google.com/p/autofac/issues/detail?id=24

Container.Activating Event Fires Twice on FactoryScoped and ContainerScoped Items

From [email protected] on March 21, 2008 03:00:16

See the following thread for more information: http://groups.google.com/group/autofac/browse_thread/thread/12fe1e58e7586b6 5

Original issue: http://code.google.com/p/autofac/issues/detail?id=48

Support additional XML config files

From [email protected] on March 10, 2008 19:17:49

It would be handy if Autofac supported multiple configuration files, e.g if
ConfigurationSettingsReader accepted an additional 'file' parameter, and if
the standard XML config support could reference other config files.

Original issue: http://code.google.com/p/autofac/issues/detail?id=42

Automate Sandcastle API doc generation

From [email protected] on March 04, 2008 19:06:57

Need to build this through NAnt whenever the distrib target is executed.

Original issue: http://code.google.com/p/autofac/issues/detail?id=40

Support for .NET 2.0

From [email protected] on February 05, 2008 09:30:02

What steps will reproduce the problem? 1. autofac currently requires .NET 3.5, while .NET 2.0 will mean that you
don't get all the beauty of C#3.0, It looks to be a very useful library. What is the expected output? What do you see instead? A .NET 2.0 version could still utilize a lot of autofac. What version of the product are you using? On what operating system? 1.0.7.33480 Please provide any additional information below.

Original issue: http://code.google.com/p/autofac/issues/detail?id=25

Simplified interfaces to handling component registrations

From [email protected] on March 10, 2008 19:38:22

IComponentRegistration and the related functionality in IContainer is
fairly terse - you can get a lot of information from them but not in the
most straightforward manner.

It would be good to provide extension methods designed to assist people
writing container extensions, either in Autofac.Component or a nested
namespace.

Some examples:

• Interfaces provided by a component
• Names applied to a component
• Components supporting an interface
• Components with a particular name

Also some discussion from Luke Schafer here: http://codesugar.com/index.php?itemid=5 .

Original issue: http://code.google.com/p/autofac/issues/detail?id=43

Provided Instances are not disposed unless they are resolved

From [email protected] on November 11, 2007 17:43:50

Probably not a big deal as provided instances will always be singletons
(otherwise they can be created upon request using an expression.)

See ignored test in ContainerBuilderFixture.

Original issue: http://code.google.com/p/autofac/issues/detail?id=7

Expose implementation type

From [email protected] on March 10, 2008 20:19:26

IComponentRegistration does not provide the implementation type for a
service. This is because none of the core should depend on this information

• in many cases it is not available or cannot be reliably determined, e.g. in:

builder.Register(c => SomeClass.GetService());

...where GetService() returns an interface.

In many other cases, this information is available and would be useful in
implementing container extensions.

The implementation type can be reliably inferred when registering:

• a System.Type
• an instance
• a delegate whose return type is concrete (even in the abstract case)

When this information is not available, there are a few strategies:

• don't provide anything at all (e.g. null? no Autofac properties
  currently return null - possibly TryGetImplementationType? hmm) - prevents
  confusion
• return typeof(System.Object) - useless but no NullReferenceException worries
• return any known interface type (a bit unpredictable)
• design the API in such a way that it is natural to fall back to
  determining the type of each instance (inefficient but correct.)

Changes potentially required in Component.Registration and subclasses, as
well as Registrar and subclasses.

Original issue: http://code.google.com/p/autofac/issues/detail?id=44

IComponentRegistration extended properties

From [email protected] on February 29, 2008 23:25:37

Enhancement : Urgent

Add a property
IDictionary<string, object> ExtendedProperties

on the IComponentRegistration to keep special informations that can be
used/set on registration, activation...

A method as .WithExtendeProperty(string, object) must be add to the
ContainerBuilder

Original issue: http://code.google.com/p/autofac/issues/detail?id=37

Replace ServiceKeyGenerator with ServiceKey

From [email protected] on November 11, 2007 12:00:04

The ServiceKeyGenerator class creates unique string keys based on other
strings or service types. A better design would encapsulate the underlying
identifier in a ServiceKey type, subclassed by TypeServiceKey and
NameServiceKey.

Original issue: http://code.google.com/p/autofac/issues/detail?id=1

Re-test under trunk version of Mono

From [email protected] on November 11, 2007 12:17:49

Bug https://bugzilla.novell.com/show_bug.cgi?id=324611 in Mono prevents use
of Autofac under Linux. Developer has suggested that latest trunk version
of Mono will work. Need to re-test.

Original issue: http://code.google.com/p/autofac/issues/detail?id=4

Refactor the various Registrars

From [email protected] on December 04, 2007 19:53:14

Need to reorganise the interface and implementation hierarchies so that
each registrar exposes only the configuration options that its implementer
supports.

Original issue: http://code.google.com/p/autofac/issues/detail?id=14

Reinstate Accumulating Collections

From [email protected] on November 11, 2007 12:09:53

Accumulating collections were removed in revision r22 .

This feature will provide a great foundation for building plugin systems
etc, however the original implementation was in the container core rather
than a facility. To avoid breaking API changes it was removed for the 1.0
release.

The new implementation of this feature should:

• Work predictably with nested containers
• Delegate element creation to the container using the string-keyed
  TryResolve()
• Respect instance scope
• Use an explicit syntax to accumulate element registrations, so that a
  default service of the element type can be registered along side the
  collection type

Original issue: http://code.google.com/p/autofac/issues/detail?id=2

Move some IConcreteRegistrar members up to IRegistrar

From [email protected] on March 17, 2008 21:38:32

As() and Named() can both be applied to generic components, as there is no
reason for these to be unique. The presence of Id on IConcreteRegistrar
reinforces this now.

At the same time it may be wise to clean up IRegistrar by removing the
As<,>() and As<,,>() overloads since multiple calls to As() are now additive.

Original issue: http://code.google.com/p/autofac/issues/detail?id=47

Autofac.DotNet2.dll is not strongly signed.

From [email protected] on February 13, 2008 15:16:20

What steps will reproduce the problem? 1. Use Autofac.DotNet.dll in a assembly that is strongly signed. What version of the product are you using? On what operating system? Autofac.DotNet2.dll version 1.0.8.190 Please provide any additional information below. We ship strongly signed assemblies so we can't use Autofac unless it is
strongly signed or uses delay signing.

Is it possible to patch the current version and sign it?

Original issue: http://code.google.com/p/autofac/issues/detail?id=29

Builder syntax does not suport names

From [email protected] on November 18, 2007 17:39:56

To name components it is currently necessary to use the Container
interface. Add a Named(name) method to the builder.

Original issue: http://code.google.com/p/autofac/issues/detail?id=10

Provide extensibility points for ContainerBuilder

From [email protected] on December 04, 2007 07:48:03

By refining the ContainerBuilder API third-party facilities can use
extension methods to get first-class builder syntax support.

Working on this in conjunction with #1 and #2.

Original issue: http://code.google.com/p/autofac/issues/detail?id=12

Simplify circular ctor/property and property/property dependencies

From [email protected] on November 14, 2007 06:19:28

In v. 1.0.1 to handle circular dependencies a manual 'hack' must be used in
the activators/OnActivated handlers to wire up circular deps (the usual way
to inject properties is OnActivat_ing_.)

This use case can be greatly improved if the OnActivated handlers run once
the component is made available to the container - InjectProperties can be
used as normal (though OnActivating is really the correct place in other
scenarios.)

The only problem I can see with this is that doing so in factory lifecycle
scenarios will cause an infinite recursion - perhaps the circular reference
checker can be extended to be permissive about a single loop but fail after
more than one identical recursion is detected?

Original issue: http://code.google.com/p/autofac/issues/detail?id=9

Some registrar types returned from builders are redundant

From [email protected] on February 10, 2008 10:39:10

ICollectionRegistrar, IProvidedInstanceRegistrar and IDelegateRegistrar can
all be replaced with a non-generic implementation of IConcreteRegistrar.

Original issue: http://code.google.com/p/autofac/issues/detail?id=27

Base class for builders

From [email protected] on March 14, 2008 20:11:03

Refactor ContainerBuilder into itself and common base class shared with
Module. This will prevent inappropraite memebers like DefaultOwnership and
DefaultScope being exposed by modules.

Original issue: http://code.google.com/p/autofac/issues/detail?id=46

Activating handlers not transferred to subcontainers

From [email protected] on December 11, 2007 08:13:38

In versions prior to 1.0.5, Activating and Activated handlers for
components with factory or container lifecycle were not fired in
subcontainers. Fixed and tested in 1.0.5.

Original issue: http://code.google.com/p/autofac/issues/detail?id=16

Expose an interface for containers

From [email protected] on January 25, 2008 22:41:34

IContainer currently exists inside Autofac as a means of communication
between elements of a container hierarchy. This will need to be renamed,
the exposed container interface will assume this name and will derive from
IContext to provide more of the Autofac.Container features. Two derived
interfaces - one exposing Register and the other not, might be appropriate.

Original issue: http://code.google.com/p/autofac/issues/detail?id=23

Create standard ASP.NET integration

From [email protected] on January 25, 2008 22:36:26

A pre-built integration for ASP.NET will benefit a large number of people
working in this environment.

Once this is done, the MVC integration should be layered on top of it.

The primary requirements of this integration are:

• Injection of dependencies into Pages and Controls
• Per-request container disposal
• Minimisation of static dependencies
• Flexible enough to accommodate multiple container scoping schemes
• Easy to configure
• Reasonably testable code...

Ideally Pages should be able to be injected into without disrupting the
inheritance hierarchy, e.g. by using [InjectProperties] or a similar
attribute in conjunction with an HTTP Module. Perhaps additional attributes
targeting members could be used to implement recursive injection.

Base classes for Pages and Controls should also be provided for those not
wishing to install an HTTP Module.

Original issue: http://code.google.com/p/autofac/issues/detail?id=22

Create a better example application

From [email protected] on February 19, 2008 08:07:22

The current examples are really thrown together and don't show off the
features of the container very well.

Possibly create a web app (MVC or ASP.NET?) that also exposes a WCF service
consumed by some kind of desktop client app.

NHibernate and log4net would be worthwhile components as well.

This will supersede the existing examples.

Original issue: http://code.google.com/p/autofac/issues/detail?id=30

Solution changes: strong name signing, conditional AllowNonTrustedCode, package examples in the same integration cycle

From rinat.abdullin on January 25, 2008 20:30:53

1. Add strong name signing and conditional AllowNonTrustedCode support in
   build script (used for assembly deployments in MediumTrust scenarios)
2. Build, Test and package examples (sources) in the same integration cycle.
3. Document #1 in the Deployment.

Original issue: http://code.google.com/p/autofac/issues/detail?id=21

Cast automatically when querying component by name (Enhancement)

From [email protected] on February 25, 2008 03:24:29

Enhancement
Avoid casting when query component by name

Must implement c.Resolve(new NamedService("Foo1"))
instead of (IFoo)c.Resolve(new NamedService("Foo1")

By the way, what is the rule the container applies to get a component for a
type if there's multiple components register for this type as in the above
sample.
As far I have see, it returns the last component register for this type, it
is always the case ?

Example
var builder = new ContainerBuilder();

        builder.Register<Foo1>().As<IFoo>().Named("Foo1");

        builder.Register(c =>
            new Foo2(
                (IFoo)c.Resolve(new NamedService("Foo1")))
            ).As<IFoo>().Named("Foo2");

        var container = builder.Build();
        IFoo foo = container.Resolve<IFoo>();

Original issue: http://code.google.com/p/autofac/issues/detail?id=32

Create the canonical 'Startable' module

From [email protected] on February 28, 2008 08:24:57

To enable and demonstrate container extensibility, add a version of the
typical 'startable' facility that works effectively through an orthogonal
implementation with minimal performance overheads.

E.g.

builder.Register(new StartableModule(s => s.Start()));

Should Start() any component instance created by the container, regardless
of whether the registration happens before or after the registration of the
Startable module.

IStartable in this instance is a placeholder - any type should be able to
be used as this maintains the unintrusiveness of the container.

To make this happen, the following APIs must be exposed:

IEnumerable IContainer.ComponentRegistrations
event IContainer.ComponentRegistered

To improve developer experience the above will be augmented with:

IComponentRegistration IContainer.DefaultRegistrationFor(Service service)

And possibly:

IEnumerable RegistrationsProviding(Service service)

Although the latter can easily be obtained using ComponentRegistrations and
a Select predicate.

The Module base type will be extended to hide the mechanics of enumerating
existing registrations and attaching to new ones with one virtual method:

virtual void AttachToRegistration(IContainer container,
IComponentRegistration registration)

Using this method the Startable facility can insert itself into the
OnActivated handler pipeline for only those components exposing IStartable.

Note, custom decommission steps will not be provided as IDisposable is the
correct place to handle this.

Original issue: http://code.google.com/p/autofac/issues/detail?id=34

Separate component descriptors from registration?

From [email protected] on March 04, 2008 19:09:59

This interface represents two distinct pieces of the registration - its
descriptor (Id, Services, ...) and the registration that performs the
necessary mechanics in a single container. Might be appropriate to move
'descriptor' part (that is shared between containers in a hierarchy) to a
separate interface and somehow link the two.

Original issue: http://code.google.com/p/autofac/issues/detail?id=41

CreateFromStrongFactory test fails under Mono 1.2.6

From [email protected] on December 15, 2007 19:19:12

Autofac.Tests.Component.Registration.ContextAwareDelegateRegistrationFixture.CreateFromStrongFactory
: System.Exception : Compiler Errors:
10,121 : Identifier expected

at
Autofac.Component.Activation.InterceptingDelegateActivator.BuildAssembly
(System.String source, IEnumerable`1 references) [0x00000]
at
Autofac.Component.Activation.InterceptingDelegateActivator.BuildImplementor
(System.Type creator) [0x00000]
at Autofac.Component.Activation.InterceptingDelegateActivator..ctor
(System.Type creator, Autofac.Component.ComponentActivator activator)
[0x00000]
at Autofac.Component.Registration.ContextAwareDelegateRegistration..ctor
(System.Type creator, Autofac.Component.ComponentActivator activator)
[0x00000]
at
Autofac.Tests.Component.Registration.ContextAwareDelegateRegistrationFixture.CreateFromStrongFactory
() [0x00000]
at (wrapper managed-to-native)
System.Reflection.MonoMethod:InternalInvoke (object,object[])
at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags
invokeAttr, System.Reflection.Binder binder, System.Object[] parameters,
System.Globalization.CultureInfo culture) [0x00000]

Original issue: http://code.google.com/p/autofac/issues/detail?id=18

Investigate and potentially remove spurious locking in ContainerScope

From [email protected] on March 02, 2008 09:25:01

ContainerScope uses a mutex to ensure that a single instance is created per
container. This might be unnecessary because Registration serialises
potentially mutating access to the scope using its own lock. Need to
investigate, should consider the 'protected internal IScope Scope' member.

Original issue: http://code.google.com/p/autofac/issues/detail?id=38

Consider options for modifying parameters before instantiation

From [email protected] on March 23, 2008 09:08:58

E.g. to provide additional dependencies on a component-by-component basis.

See thread http://groups.google.com/group/autofac/browse_thread/thread/449789607b49f8c8 for more information.

If more events are added for the purpose, consider creating
IComponentLifecycleEvents from IContainer and IComponentRegistration.

Original issue: http://code.google.com/p/autofac/issues/detail?id=49

Keep it up & going

From [email protected] on December 09, 2007 20:22:22

Very nice work done here man. Going to use it in some production projects
after comparing with mirrokernel!

Original issue: http://code.google.com/p/autofac/issues/detail?id=15

Cache results of constructor searches

From [email protected] on November 11, 2007 17:27:38

The results of constructor searches in the ReflectionActivator should be
cached on a per-container or per-container-hierarchy basis. The cached
results can be kept until a component is registered in the current or any
outer container.

Rather than caching ConstructorInfo, DynamicMethod might be a better option.

Original issue: http://code.google.com/p/autofac/issues/detail?id=5