What are your plans in creating and maintaining an Autofac adapter for the ASP.NET vNext DI system?

[dotnetjunkie]

I'm interested to know whether or not the Autofac team has decided to take over the maintenance of the ASP.NET DI adapter for Autofac that the ASP.NET team built.

As discussed by Mark Seemann here and on the Simple Injector forum (in discussion with David Fowler) here, implementing such adapter has some serious downsides; even for Autofac. The discussion on the Simple Injector forum also shows a very compelling alternative that is applicable for any possible DI container (and applicable when practicing Pure DI).

So I'm very interested to hear whether your team is planning to support such adapter, or whether you favor a guidance similar to given on the Simple Injector forum. I really like to hear your opinions and motivations behind this.

[tillig]

We do plan on supporting the DNX integration as outlined by the ASP.NET team. You can see our implementations of the various interfaces in the Autofac.Dnx integration here.

I've read the Seeman post on conforming containers and had some Twitter discussion over it. Pretty sure @alexmg has, too. I think there are pros and cons to each way - I get why the DNX guys did what they did, but I also get how you lose some flexibility by creating a universal interface.

There are probably going to be several new devs coming in with DNX - devs that are familiar with other stacks but not the .NET stack. Folks on other OS/platforms than before. All the examples and documentation on DNX will show folks how to do things using the predetermined DNX integration mechanism.

I also know personally how painful it has been to get DNX things up and running. The whole stack feels like building on top of Jell-o with the amount of change going on. Anything we can do to standardize and remove the extra work from the dev could be good.

From that standpoint - getting new devs up and running, keeping things stable and common - I feel it's valuable to use what they've provided even if it's not optimal.

Great example of this is filters in Web API. Web API caches the junk out of everything to "optimize performance" but it basically means we had to create our own Web API filter provider and filter types and everything in order to get full, robust DI in place. Having to maintain our own version of stuff rather than being able to hook into something existing has been painful to maintain, painful to answer questions about, painful for people to get set up. I would love it if Web API had provided even a slightly-less-than-optimal solution to this that we could have leveraged rather than us having to support all the infrastructure ourselves.

I don't think this precludes us from having integration options. We could offer, say, a "basic" and "advanced" option. The "basic" option might be "use the conforming container like you see in DNX examples and things will work but you lose a bit of flexibility." The "advanced" option might be "don't use the DNX container; instead integrate using these additional configuration settings and options to enable a far more flexible environment."

I don't have anything concrete to offer in the way of the "advanced" option I reference. We're really just trying to get "basic" working in a stable fashion first.

Finally, the MVC and Web API DependencyResolver instances have been conforming containers we've kind of had to eat for a long time. The DNX stuff is actually an improvement in comparison. While not perfect, I have to admit it's better, and there's something to be said for that.

[dotnetjunkie]

the MVC and Web API DependencyResolver instances have been conforming containers we've kind of had to eat for a long time

I think you are mixing things up here. The DependencyResolvers are Service Locators. They are not conforming containers, because they don't lay any constraint on the registration phase. Registrational behavior is what makes something a conforming container. I agree, the DepedencyResolver implementations aren't the best design, but they don't limit our IoC libraries in any way.

I don't have anything concrete to offer in the way of the "advanced" option I reference.

Well, I do actually. I highly recommend anyone to read this discussion. It shows how you can integrate Simple Injector into the vNext pipeline without using the adapter approach (but note that this works with any container). Later on in the thread, I give some very concrete examples of where the conforming container model breaks all our container implementations. This is not only explained for Simple Injector, but the discussion includes Autofac, Ninject, Windsor and Unity as well.

My advice is to describe in the Autofac documentation how to integrate with vNext by using an example that is similar to the one shown here. IMO this should be the default example, but I can follow you if you want to offer your users an alternative choice, such as using a conforming container adapter. But please do make very sure that this adapter implementation doesn't break nNext's contract.

Unfortunately, not breaking the contract this is actually the hard part, because much of the contract is implicit and undefined. Again, this discussion explains some of vNext DI system's contract, but this is just the top of the iceberg. I can ensure you, there will be many more of these details that you didn't know existed, but where application developers, third party component developers, and ASP.NET framework developers will depend on in the coming years.

All the examples and documentation on DNX will show folks how to do things using the predetermined DNX integration mechanism.

But this is simply a matter of choice. If we as IoC container builders all decide to not implement any adapter, and guide our users to a 'conformless' solution, the ASP.NET team has no option but change their documentation examples as well. They will have to, because they are depending on us to maintain the adapter implementations; they already explained that they will not maintain the adapters themselves. And to be honest, I think by now they realized that their adapter-guidance isn't the best guidance they can give.

But the funny thing is however, that the new ASP.NET DI system itself doesn't limit our IoC libraries in any way at all. As I've shown, you can plug in anything with any ease. But for some weird reason (or at least, weird in my opinion), someone at Microsoft decided to communicate that the best way to use your own IoC container is by completely replacing the built-in one. This decision lead to two example adapter implementations, blog posts and MSDN articles and this is the sole reason why we are now forced into this unfortunate path.

Again, I think we can make the change happen with Microsoft. This can happen, because there is no single line of code that the ASP.NET team has to change in DNX. It's just a matter of discarding the old guidance and write some new documentation. And as I already shown, the solution I'm proposing is actually way simpler. Container specific integration libraries are still useful (for doing things like RegisterControllers for instance), but adapters don't have to be included.