foxaaa / autofac Goto Github PK
View Code? Open in Web Editor NEWAutomatically exported from code.google.com/p/autofac
Automatically exported from code.google.com/p/autofac
See the following thread for more information:
http://groups.google.com/group/autofac/browse_thread/thread/12fe1e58e7586b6
5
Original issue reported on code.google.com by [email protected]
on 20 Mar 2008 at 5:00
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 reported on code.google.com by [email protected]
on 25 Jan 2008 at 12:36
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 reported on code.google.com by [email protected]
on 13 Nov 2007 at 8:19
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>();
Original issue reported on code.google.com by [email protected]
on 18 Feb 2008 at 10:13
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 reported on code.google.com by [email protected]
on 10 Mar 2008 at 9:38
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 reported on code.google.com by [email protected]
on 13 Feb 2008 at 5:16
Enhancement
The container should do auto injection of properties if he can
It can be an option to set
Original issue reported on code.google.com by [email protected]
on 29 Feb 2008 at 12:59
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)
Original issue reported on code.google.com by [email protected]
on 28 Mar 2008 at 4:34
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 reported on code.google.com by [email protected]
on 4 Feb 2008 at 11:30
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]
Original issue reported on code.google.com by [email protected]
on 15 Dec 2007 at 9:19
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 reported on code.google.com by [email protected]
on 18 Feb 2008 at 10:07
These will still benefit .NET 2.0 users.
Original issue reported on code.google.com by [email protected]
on 9 Feb 2008 at 8:56
Namely, support constructor selection, instance scope, instance ownership.
Original issue reported on code.google.com by [email protected]
on 12 Nov 2007 at 11:18
ICollectionRegistrar, IProvidedInstanceRegistrar and IDelegateRegistrar can
all be replaced with a non-generic implementation of IConcreteRegistrar.
Original issue reported on code.google.com by [email protected]
on 10 Feb 2008 at 12:39
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 reported on code.google.com by rinat.abdullin
on 25 Jan 2008 at 10:30
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 reported on code.google.com by [email protected]
on 10 Dec 2007 at 10:13
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 reported on code.google.com by [email protected]
on 11 Nov 2007 at 2:17
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 reported on code.google.com by [email protected]
on 1 Mar 2008 at 11:25
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 reported on code.google.com by [email protected]
on 17 Mar 2008 at 11:38
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 reported on code.google.com by [email protected]
on 10 Feb 2008 at 12:58
This should be Mono-compatible so that it can be used on a Linux CI server
if necessary.
Original issue reported on code.google.com by [email protected]
on 14 Jan 2008 at 10:53
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 reported on code.google.com by [email protected]
on 25 Jan 2008 at 12:41
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
Original issue reported on code.google.com by [email protected]
on 29 Feb 2008 at 1:14
To name components it is currently necessary to use the Container
interface. Add a Named(name) method to the builder.
Original issue reported on code.google.com by [email protected]
on 18 Nov 2007 at 7:39
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 reported on code.google.com by [email protected]
on 10 Mar 2008 at 9:17
Need to build this through NAnt whenever the distrib target is executed.
Original issue reported on code.google.com by [email protected]
on 4 Mar 2008 at 9:06
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 reported on code.google.com by [email protected]
on 15 Dec 2007 at 9:18
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 reported on code.google.com by [email protected]
on 13 Mar 2008 at 11:39
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 reported on code.google.com by [email protected]
on 11 Nov 2007 at 2:00
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 reported on code.google.com by [email protected]
on 11 Nov 2007 at 7:43
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 reported on code.google.com by [email protected]
on 18 Nov 2007 at 8:15
The activator for this type needs the list of services that the
registration covers - this will be distinct per context.
Original issue reported on code.google.com by [email protected]
on 4 Dec 2007 at 9:52
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>();
Original issue reported on code.google.com by [email protected]
on 24 Feb 2008 at 5:24
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 reported on code.google.com by [email protected]
on 10 Mar 2008 at 10:19
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 reported on code.google.com by [email protected]
on 3 Dec 2007 at 9:48
Very nice work done here man. Going to use it in some production projects
after comparing with mirrokernel!
Original issue reported on code.google.com by [email protected]
on 9 Dec 2007 at 10:22
DynamicMethod is a more efficient means of generating factory delegates
than C# compilation. Implementation should replace
InterceptingDelegateActivator.
Original issue reported on code.google.com by [email protected]
on 11 Nov 2007 at 2:14
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 reported on code.google.com by [email protected]
on 11 Nov 2007 at 2:09
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 reported on code.google.com by [email protected]
on 22 Mar 2008 at 11:08
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 reported on code.google.com by [email protected]
on 11 Nov 2007 at 7:27
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 reported on code.google.com by [email protected]
on 29 Feb 2008 at 1:25
A-la the one available for Windsor/Monorail.
Original issue reported on code.google.com by [email protected]
on 11 Nov 2007 at 7:34
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 reported on code.google.com by [email protected]
on 14 Mar 2008 at 10:11
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 reported on code.google.com by [email protected]
on 3 Jan 2008 at 7:46
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 reported on code.google.com by [email protected]
on 4 Mar 2008 at 9:09
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.
Original issue reported on code.google.com by [email protected]
on 27 Feb 2008 at 10:24
Rather than creating and registering unique service names, do this in the
registrar.
Original issue reported on code.google.com by [email protected]
on 25 Feb 2008 at 10:38
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 reported on code.google.com by rinat.abdullin
on 3 Feb 2008 at 10:27
Need to reorganise the interface and implementation hierarchies so that
each registrar exposes only the configuration options that its implementer
supports.
Original issue reported on code.google.com by [email protected]
on 4 Dec 2007 at 9:53
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 reported on code.google.com by [email protected]
on 2 Mar 2008 at 2:33
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.