Autofac on UserVoice

WPF Walkthrough [updated]

2012-01-16T15:53:32-08:00

Create an end-to-end walkthrough showing how to set up Autofac with Windows Presentation Foundation (WPF). Include a sample application.

mabster said:

Comicster might serve as an example.

http://comicster.net
https://bitbucket.org/mabster/comicster

add a HasKey method to IIndex

2012-01-15T20:24:39-08:00

mabster suggested:
Currently if I want to determine if a class is registered with a specific key I have to use IsRegistered on the container, or TryGetValue on IIndex<TKey, TValue>. It'd be nice if IIndex had a HasKey(TKey key) method, returning bool, to simplify this test.

Support FSharpFunc

2011-10-11T14:05:46-07:00

xepaul suggested:
Dynamic instantiation, and parameterisation is supported via func's, it would be very use if it was also supported via FSharpFunc's

Support Compact Framework (.NET CF) [updated]

2011-08-09T06:20:58-07:00

Add a build configuration for .NET CF.

Don Konfetti said:

There's no serious IoC container available for .NET CF. So, Autofac supporting .NET CF would be great!

Extend XML Configuration [updated]

2011-07-12T09:02:48-07:00

Most Autofac applications use code to register services, and where necessary register only Modules via XML. Some users have expressed interest in adding more fine-grained component registration to the XML sytax: Examples: * Constructor selection policy * Tags * Factory Methods * Open generic types * Resolve named services as constructor parameters

Tomek Pluskiewicz said:

Please add to the list ability to configure constructor/property injection for components registered in code (this is a feature I used extensively in Windsor)

ASP.NET MVC integration demo in trunk [updated]

2011-01-09T00:20:32-08:00

Andrew Ma said:

there are files in /examples and /src/examples, my guess is the creator is asking to clean this up to have it in one location

Add a NuGet package for MVC3 integration

2011-01-09T00:18:50-08:00

Utilize Expression Trees in RegisterType() to improve Resolve() performance [is now declined]

2010-12-23T19:48:52-08:00

I've implemented a custom Attributes and Modules to enable attribute driven configuration (registration declarations). To improve Resolve() performance, my modules use reflection and expression trees to produce the construction delegates, registering them via RegisterCallback() instead of simply calling RegisterType. I believe RegisterType() could use similar logic to eliminate the current overhead during Resolve().

Utilize Expression Trees in RegisterType() to improve Resolve() performance [updated]

2010-12-23T19:48:52-08:00

nicholas.blumhardt (admin) responded:

Thanks again.

Utilize Expression Trees in RegisterType() to improve Resolve() performance [updated]

2010-12-22T10:31:14-08:00

Kevin Meyer said:

Thanks for the response. I took at look at the source and see what you mean. There's a bit more sophistication in the constructor parameter binding than I realized.

Very clean code, by the way.

Utilize Expression Trees in RegisterType() to improve Resolve() performance [updated]

2010-12-19T14:13:11-08:00

nicholas.blumhardt said:

Thanks for the suggestion, Kevin. The dynamic nature of constructor resolution in Autofac makes this practically impossible - thankfully if you have a performance-sensitive scenarion, profile your app, and Autofac turns out to be significant, you usually find that 90% of instantiations are the same handful of components. Switching these to single-instance (crazy fast) or registering them with a lambda (just about as fast) is a simple way to eliminate reflection overhead.

Move types like Meta<>, Owned<> to independent assembly [updated]

2010-09-16T14:18:02-07:00

This would aid in the goal of Zero Intrusion (Components don't need to reference Autofac). It would allow components to be descriptive about their relationships without needing to reference the Autofac assembly.

Robert Hencke said:

I'm sorry for the late reply. Sure, I'd be happy to.

Add Support to create custom IScope [updated]

2010-08-18T15:49:52-07:00

Currently it has the IScope but internally it uses the enum which restricts to create custom scope such as PerWebRequest. The current recommended way to create a child container is very similar to Unity but not like other container.

nicholas.blumhardt said:

Howdy, It might be worth checking out HttpRequestScoped() in the Autofac.Integration.Web project. Autofac does allow creation of custom scopes, but the scope hierarchy has to be represented explicitly using child lifetimes scopes. Cheers!

Move types like Meta<>, Owned<> to independent assembly [updated]

2010-08-18T15:46:28-07:00

nicholas.blumhardt said:

Hi Robert,

I've kicked off some work to do with this - would you be interested in lending a hand? If so let me know and I'll add you to the (independent from Autofac) project.

Cheers,
Nick

Improved registration of types as their interfaces [updated]

2010-08-18T15:44:53-07:00

I typically use a fair amount of interfaces to make testing/stubbing easier. One slight pain I have with Autofac is registering a type .As() an interface it implements. Not a huge pain, but it would be nice to be able to write it much more cleanly. At current I use reflection to do this. It would be nice instead if RegisterTypesFromAssembly() or RegisterTypesMatching() could be extended to do this. Something like: RegisterTypesAssignableFrom(ICommand).AsInterface() where AsInterface works out the interface the type implements directly. Bit messy but you get the idea.

nicholas.blumhardt said:

Hi Robert,

We ended up with:

builder.RegisterAssemblyTypes()
.AssignableTo<ICommand>()
.AsImplementedInterfaces();

How does this go towards your original suggestion?

Cheers!
Nick

Move types like Meta<>, Owned<> to independent assembly

2010-08-18T06:59:36-07:00

Robert Hencke suggested:
This would aid in the goal of Zero Intrusion (Components don't need to reference Autofac). It would allow components to be descriptive about their relationships without needing to reference the Autofac assembly.

Support C# 4.0 optional parameters for constructor resolution [is now completed]

2010-07-12T21:11:42-07:00

Support C# 4.0 optional parameters for constructor resolution [updated]

2010-07-12T21:11:42-07:00

nicholas.blumhardt (admin) responded:

Done - see example on http://autofac.org
- Default parameter values can be used to express optional dependencies (properties can be used instead if you prefer):

public TaskController(ITaskRepository tasks, ILog log = null)

Registration conventions [is now completed]

2010-07-12T21:09:45-07:00

Not really sure how to put this in words or if there's a real use case. But was thinking of conventions that could be defined, and Autofac regsiters everything matching that convention. Sort of like FluentNHibernate's AutoMapping. So for example, anything that implements a single interface, register it as that interface. Or, anything such as Converter<UserDto, User> where there are two types, register it using the former type, ie IConverter<UserDto> This would make registration simpler, and also you could unit test your convention checking that certain types have been registered.

Registration conventions [updated]

2010-07-12T21:09:45-07:00

nicholas.blumhardt (admin) responded:

Thanks all - this suggestion has been implemented as 'scanning registrations' via RegisterAssemblyTypes(). See http://code.google.com/p/autofac/wiki/Scanning

Please come forth and suggest, folks! [is now none]

2010-04-02T19:31:44-07:00

Autofac is waiting for your ideas :)

Resolve open generic interfaces by constraint [updated]

2010-02-20T15:39:09-08:00

Support resolving open generics by the most specific constraint. For example: class MyService<T> { } class MyFooService<T> : MyService<T> where T : IFoo { } b.Register<MyService<>>(); b.Register<MyFooService<>>().As<MyService<>>() c.Resolve<MyService<object>>() // gets a MyService c.Resolve<MyService<FooImplementor>>() // gets a MyFooService

nicholas.blumhardt said:

From r779, Autofac 2 will verify open generic parameter constraints before providing a generic implementation (http://code.google.com/p/autofac/source/detail?r=779)

Which implementation is resolved depends on the order of registration though and not specificity of the constraint (interesting suggestion.)

Resolve open generic interfaces by constraint

2010-02-18T07:52:58-08:00

Ilia Jerebtsov suggested:
Support resolving open generics by the most specific constraint. For example: class MyService<T> { } class MyFooService<T> : MyService<T> where T : IFoo { } b.Register<MyService<>>(); b.Register<MyFooService<>>().As<MyService<>>() c.Resolve<MyService<object>>() // gets a MyService c.Resolve<MyService<FooImplementor>>() // gets a MyFooService

"Internal" components.

2010-02-12T08:43:04-08:00

an anonymous user suggested:
I would like to be able to register "internal" components which only can be accessed from within the same assembly as the requested type. It's quite easy to implement. Simply call Assembly.GetCallingAssembly() when a component flagged with "Internal" are requested.

Allow Interface<T> to Class<T,S> mapping supplying S argument in Resolve method

2010-02-12T04:22:37-08:00

Add Support to create custom IScope

2010-01-11T15:03:32-08:00

an anonymous user suggested:
Currently it has the IScope but internally it uses the enum which restricts to create custom scope such as PerWebRequest. The current recommended way to create a child container is very similar to Unity but not like other container.

Support Prism from Microsoft Patterns & Practices [is now planned]

2010-01-01T01:01:07-08:00

Prism is a composite application framework created by Microsoft P&P. There is a sample integration here: http://autofac.googlegroups.com/web/prizm.zip_. Please add your vote if you'd like to see this added to Autofac Contrib.

Support Prism from Microsoft Patterns & Practices [updated]

2010-01-01T01:01:07-08:00

nicholas.blumhardt (admin) responded:

This is the top-voted item and so it is moving to the Autofac issue tracker as a planned item within the 2.1 milestone.

See http://code.google.com/p/autofac/issues/detail?id=178.

Support IModule buildup using MEF

2009-10-27T15:40:52-07:00

steve.hebert suggested:
Support Export(typeof(IModule)) in Builder implementation. Perhaps add the support of named IModule types through the use of an attribute to filter the modules at load time.

Extend XML Configuration [updated]

2009-09-13T21:42:01-07:00

Rinat Abdullin said:

Hm... may be Boo-based initialization would be more flexible?
XML feels horrible for anything that usually requires dealing with types or with lambdas.

Support for "dynamic" instances via DLR

2009-09-12T01:12:58-07:00

CVertex suggested:
Maybe this is already supported, so maybe a walkthrough/wiki about how to inject dynamic components

ASP.NET MVC integration demo in trunk [updated]

2009-09-12T00:55:34-07:00

CVertex said:

Not sure who posted the original suggestion, but i'd like to see examples of Filter, ModelBinder injection in the demo - not just controller injection.

Extend XML Configuration [updated]

2009-08-15T23:21:27-07:00

nicholas.blumhardt said:

When voting for this item, please give an indication of which features are important to you :)

ASP.NET MVC integration demo in trunk [updated]

2009-08-15T08:39:43-07:00

nicholas.blumhardt (admin) responded:

I might not understand your suggestion - there is already a basic MVC demo in trunk, see the Remember* projects in the main solution. Can you give some more details? Thanks!

ASP.NET MVC integration demo in trunk

2009-08-14T03:06:16-07:00

Support Prism from Microsoft Patterns & Practices [updated]

2009-08-06T21:53:57-07:00

nicholas.blumhardt said:

The sample from the above link is now in Subversion and briefly documented here: http://code.google.com/p/autofac/wiki/PrismIntegration?ts=1249620682&updated=PrismIntegration

WinForms Walkthrough

2009-08-05T22:10:03-07:00

nicholas.blumhardt suggested:
Create an end-to-end walkthrough showing how to set up Autofac with Windows Forms (WinForms). Include a sample application.

ASP.NET MVC Walkthrough

2009-08-05T22:09:24-07:00

nicholas.blumhardt suggested:
Create an end-to-end walkthrough showing how to set up Autofac with ASP.NET MVC. Include a sample application (can be based on the Remember example in the Autofac source tree.)

WPF Walkthrough

2009-08-05T22:08:25-07:00

nicholas.blumhardt suggested:
Create an end-to-end walkthrough showing how to set up Autofac with Windows Presentation Foundation (WPF). Include a sample application.

WebForms Walkthrough

2009-08-05T22:07:39-07:00

nicholas.blumhardt suggested:
Create an end-to-end walkthrough showing how to set up Autofac with ASP.NET WebForms. Include a sample application.

Restructuring of documentation and more documentation through examples [updated]

2009-08-05T22:05:54-07:00

The documentation is good, although I still find I run into problems. a) I can't find what I'm looking for, b) I find what I'm looking for but the examples aren't clear enough to understand. Better use cases, or examples of what people are more likely to do. And also structured documentation rather than the flat wiki that currently exists.

nicholas.blumhardt said:

Would it be sufficient to make the contents page at http://code.google.com/p/autofac/wiki/Contents more noticeable?

I'm raising new suggestions for end-to-end walkthroughs under each of the major .NET application models.

Support Enterprise Library (Entlib) 5

2009-08-05T20:48:56-07:00

nicholas.blumhardt suggested:
Entlib 5 can be configured to use a third-party IoC container (other than Unity.) Please add your vote if you'd like to see an adapter added to Autofac Contrib.

Support Prism from Microsoft Patterns & Practices

2009-08-05T20:44:29-07:00

nicholas.blumhardt suggested:
Prism is a composite application framework created by Microsoft P&P. There is a sample integration here: http://autofac.googlegroups.com/web/prizm.zip_. Please add your vote if you'd like to see this added to Autofac Contrib.

Support Compact Framework (.NET CF)

2009-08-03T19:44:15-07:00

nicholas.blumhardt suggested:
Add a build configuration for .NET CF.

Extend XML Configuration

2009-08-03T19:36:15-07:00

nicholas.blumhardt suggested:
Most Autofac applications use code to register services, and where necessary register only Modules via XML. Some users have expressed interest in adding more fine-grained component registration to the XML sytax: Examples: * Constructor selection policy * Tags * Factory Methods * Open generic types * Resolve named services as constructor parameters

Registration conventions [updated]

2009-08-03T19:19:19-07:00

nicholas.blumhardt said:

Sounds good. Any suggestions for how this API would look?

Restructuring of documentation and more documentation through examples [updated]

2009-08-03T19:17:34-07:00

nicholas.blumhardt said:

Hierarchical documentation sounds good - would a single "contents" page do the trick?

I like the idea of use-case based examples, perhaps we start a new suggestion (in UserVoice) for each specific use case, so that people can vote on the ones they'd like to read?

Improved registration of types as their interfaces [updated]

2009-08-03T19:15:34-07:00

nicholas.blumhardt said:

I've thought about this quite often - the tricky part is that RegisterTypes...() and friends work lazily, while the As() part would force them to be eager.

Still, if there are more use cases that require this it could be the start of a cleaner batch registration interface.

Please come forth and suggest, folks! [is now spam]

2009-08-03T19:12:07-07:00

Autofac is waiting for your ideas :)

Registration conventions [updated]

2009-08-03T07:02:28-07:00

Robert Beal said:

Or conventions in the sense, if you have class Service, Autofac will look for IService, ServiceInterface, etc... common combinations when registering the type.