Question about Dependency Injection:
I’m currently using autofac for dependency injection in a project because I’m attempting to do a plugin architecture and it has some features for loading interfaces from dlls. I came across the Microsoft dependency injection library and learned that it can load from autofac containers with the extension. What’s the benefit of this over using autofac alone ?
19 Replies
Also on that topic do many people still use autofac since Microsoft di came out ?
I’ve also seen scrutor mentioned a lot, would that be a better library to use for my purposes ?
Unknown User•2d ago
Message Not Public
Sign In & Join Server To View
Ahh I was considering it related to DI because some DI implementations have features for loading assemblies as certain interfaces and registering them for the rest of the app
Unknown User•2d ago
Message Not Public
Sign In & Join Server To View
All the plugins will be in a specific folder so I’ll just be searching for all dlls in the folder, then registering all the classes that implement IPlugin
I know autofac has some assembly loading features so I wasn’t sure whether to use autofac, or Microsoft Di and scrutor together
Unknown User•2d ago
Message Not Public
Sign In & Join Server To View
So I’m writing a cli app that has a plugin system so users can add custom functionality and call it from the same cli app, so if you have for example an automation you just register it in the plugins folder and the app will pick it up and execute it for you
Modern dotnet, it’s a brand new project
Unknown User•2d ago
Message Not Public
Sign In & Join Server To View
I've recently added something similar based on
Microsoft.Extensions.DependencyInjection, I'm guessing you are looking for something roughly like this.
For that, there is no need to use AutoFac, just be aware that the Assembly in question must be loaded, otherwise you will not find any types populated.
While I agree with @TeBeCo, there are use cases for AutoFac, even when you are using the IServiceCollection interface (there is a neat adapter for it). For example AutoFac has support for tenant-specific containers, i.e. resolving different services based on some kind of tenant-identification (see here, but that only as a side note)Out of curiosity what’s the benefit of using the IServiceCollection interface over just the autofac container? I’m using spectre cli which lets me register any DI system so wasn’t sure if it was just for generic host support
I’m definitely still looking into autofac to see if it’s required, some of the features like xml configuration for loading in interfaces could be useful to adapt the project for different businesses that might use different log systems or want to store configurations in different formats or on the cloud.
I’m also looking into the decorator pattern autofac supports for implementing logging and other features on some interfaces provided by other libraries
Out of curiosity what’s the benefit of using the IServiceCollection interface over just the autofac container? I’m using spectre cli which lets me register any DI system so wasn’t sure if it was just for generic host supportThere is no benefit you are looking for, I guess.
IServiceCollection is a very general interface that handles registrations, nothing more. It depends on the actual container (framework) that is used behind the scenes. If you are, for example, in a Asp.Net project, then you would want to use the IServiceCollection instance, mainly because all the framework registrations also go there (so it prevents you from having a completely seperate ioc container). You can define the fwk to use for DI at startup.
some of the features like xml configuration for loading in interfaces could be useful to adapt the project for different businesses that might use different log systemsHave a look at IConfiguration here, things like that are possible with the standard container.
I’m also looking into the decorator pattern autofac supports for implementing logging and other features on some interfaces provided by other librariesAoP is certainly something that the M.E.DI container does not support, but you could make it work together with Castles Dynamic Proxy. But at that point.. it makes more sense to use something others built already for you. To be clear: I don't have anything against AutoFac, there are certainly use cases for it. Usually you just don't need it unless you want something quite nieche. I'm a bit an DI enthusiast and I had to use it only once so far, where the standard container was not sufficient. 🙂
Configuration in ASP.NET Core
Learn how to use the Configuration API to configure AppSettings in an ASP.NET Core app.
MEF?
I use autofac because it is able to provide an IoC for WCF as well as MEF
Unknown User•6h ago
Message Not Public
Sign In & Join Server To View
non taken, i didn't realise anyone truly works on non legacy codebases outside of hobby projects 😄
Unknown User•6h ago
Message Not Public
Sign In & Join Server To View
You're lucky
Don't rub it in
Unknown User•5h ago
Message Not Public
Sign In & Join Server To View
This is correct but also the crux of the problem as not a single large third party DI container can correctly implement the abstraction; it is leaky as hell.
So the only real option for library authors is to stick to MEDI and application authors can go write a bunch of integration logic to use their container of choice (thanks MS)
https://blog.simpleinjector.org/2016/06/whats-wrong-with-the-asp-net-core-di-abstraction/
specifically:
there will definitely be behavior differences between the Autofac DI container and the Microsoft DI container. We’re not trying to behave identically – if you choose to use Autofac as your backing container, you’re also choosing the Autofac behaviors. The difference in behavior you found is one of probably manyand
Considering that Microsoft’s DI Container is heavily influenced by Autofac’s design, it is a telling sign that even Autofac can’t comply with the abstraction.You will likely inevitably run into issues like those described in the article. That said, I will choose SimpleInjector as my container of choice because it is objectively superior to MEDI given my usecases.
What are your use cases that make medi better for it ?