autofac / autofac Goto Github PK
View Code? Open in Web Editor NEWAn addictive .NET IoC container
Home Page: https://autofac.org
License: MIT License
An addictive .NET IoC container
Home Page: https://autofac.org
License: MIT License
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:
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
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
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
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
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
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
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
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:
When this information is not available, there are a few strategies:
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
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
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
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
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
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:
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
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
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
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
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
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
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
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
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
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
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
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:
Original issue: http://code.google.com/p/autofac/issues/detail?id=2
From rinat.abdullin on January 25, 2008 20:30:53
Original issue: http://code.google.com/p/autofac/issues/detail?id=21
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
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
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
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
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
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
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
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
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
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
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
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
Skipping this issue number to maintain synchronization with Google Code issue IDs.
Original issue: http://code.google.com/p/autofac/issues/detail?id=91
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
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
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
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
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
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
From [email protected] on December 15, 2007 19:18:01
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
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
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
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
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
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
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
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.