Why is this repo using AutoFac instead of .NET's own DI infrastructure?

[Tony20221]

Why is this repo using AutoFac instead of .NET's own DI infrastructure?

If the repo had a discussion or a question area, I could have asked this question there. Also, I don't think Stackoverflow is the right place to ask this question since it's pretty much directed to the author.

[ardalis]

Hi @Tony20221 this is fine to ask here. I'm not turning on Discussions mainly because I don't want one more place to have to check.

To answer your question, and probably this would be a good opportunity to include an ADR, I used Autofac when the .NET DI container was still pretty new and not full-featured. I've used Autofac for longer than .NET Core has existed, and it's a very mature and stable library that has a lot of nice capabilities. Being able to put modules close to the dependencies (in the same project as the implementation classes) is one such capability, though of late it seems the de facto .NET standard is to achieve something similar using extension methods. Autofac also has nicer support for things like decorators, but out of the box I'm not using that capability here.

To be honest I have been considering removing Autofac from this template for a while now. I'm not sure it adds enough to support the extra files and concepts and dependencies it brings. I'm curious to know how others feel about that. Leave a comment or a 👍 or 👎 on this comment to show you prefer Autofac (👍 ) or not (👎 ).

[ardalis]

Yeah, the votes are pretty evident here. I'm going to remove Autofac.

[KyleMcMaster]

Just to add my 2 cents, I agree that an ADR would be good to add for this decision and it's important to note that community feedback was considered for the change (especially since it was overwhelmingly weighted to one outcome).