foxaaa / autofac Goto Github PK

See the following thread for more information:

http://groups.google.com/group/autofac/browse_thread/thread/12fe1e58e7586b6
5

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.

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?

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<T>();

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.

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?

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

What steps will reproduce the problem?
1. Reference autofac in an assembly that has 

[assembly: CLSCompliant(true)]


What version of the product are you using? On what operating system?
1.1.5.293 (dot net.2)

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.

2)
Autofac.Tests.Component.Registration.ContextAwareDelegateRegistrationFixture.Cre
ateFromStrongFactory
: 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.Cre
ateFromStrongFactory
() [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] 

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.

These will still benefit .NET 2.0 users.

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

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

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.

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.

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.

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.

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.

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.

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

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.

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<RegisteredEventArgs> handler)

This will act as a global inspector during component registration

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

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.

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

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] 

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.

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.

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.

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.

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

Enhancement
Avoid casting when query component by name

Must implement c.Resolve<IFoo>(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>();

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.

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.

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

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

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

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.

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.

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

A-la the one available for Windsor/Monorail.

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

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.

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.

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<IStartable>(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<IComponentRegistration> IContainer.ComponentRegistrations
event IContainer.ComponentRegistered

To improve developer experience the above will be augmented with:

IComponentRegistration IContainer.DefaultRegistrationFor(Service service)

And possibly:

IEnumerable<IComponentRegistration> 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.

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

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.

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

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.