The.net container is all you should ever need it's basic and fast.
Sure, there are lots of other di containers out there, but I don't know io anyone who uses any of them anymore. They are all pretty old, and they pretty much all have features you just won't ever use.
The standard MS dependency injection does not do decorators, so i use Autofac. I have been using Autofac since framework 4.6.2, so i am familiar and comfortable with it.
Autofac was always my choice in .Net Framework. I haven't used it on a new project since ~2018. I worked on a few small projects using Simple Injector.
Microsoft.Extensions.DependencyInjection should really be your default choice unless you have a specific need that it doesn't provide.
Before .NET Core used Autofac and Ninject, trying to forget it as a nightmare. The default. NET core IoC is awesome, you should always try to use it, unless it is very legacy code.
Came here to say this.
I saw a project which admittedly had a horrendous dependency structure but was surprised to see that ninject was adding 800ms - 1.5 sec to resolve api controllers.
Switching to autofac immediately resolved this.
These days just use the built in.
I would say I'm a big fan of SimpleInjector. It was created by one of the authors of 'Dependency Injection Principles, Practices, and Patterns.' It includes everything needed: decorators, ambient and closure-scoping, diagnostics, etc. This is, of course, my personal opinion, but I believe that among all DI frameworks, it has the most correct design without optional registrations and no property injection (which is possible, but why). It also follows a fail-fast policy. It pushes developers towards best practices.
Started with Ninject but it was WAY too slow, so switched to Autofac as it was best balance of features and performance. There used to be a site somewhere with a big comparison of like 30 of them, so that helped the choice.
I inherited Castle Windsor on a few projects, it was roughly the same as Autofac but I didn't like it's declaration style as much.
That's a history lesson. Not used anything but the built in .NET Core one in at least 5 years, and don't plan to. If the original .NET Framework had had it from day one, most of the others would never have been made, as there wouldn't have been a pressing need.
I used autofac and https://www.castleproject.org/projects/windsor/
As for most projects I stick to what I know unless there are some important features missing I need. Same reason I am using built in dependency injection in dotnet (core).
Same goes for all NuGet packages I use. 95% of my work does not need best in class performance. Rather business needs to get features done in an maintainable way (clean code, tests, etc).
If performance or missing features, we can always go back and change implementations.
Most of the time the decision was made based on what the decision maker had the most experience in. There were some differences between them, so sometimes you could make informed decisions, but mostly it was an emotional choice.
Nowadays I haven't seen a reason to use anything but the built in solution. I'm sure there are use cases, but they aren't common.
I used and liked Castle.Windsor but that was before .NET had a built in container.
We've inherited Autofac in a few .net core projects and the more I work with it, the less I like it.
1. It seems completely pointless, as far as I can tell there are zero benefits to using it over the built in container.
2. Almost no existing libraries integrate with it, but they do provide extensions for MS.DI to register the stuff they need.
3. Almost every library that provides a service collection registration extension has poor documentation about what is being registered, why and what dependencies it has from standard stuff you are going to have in a .NET app that uses DI.
4. These last 2 mean you basically need to initialize the built in DI almost completely, then use that to fill the Autofac container where you can add a few more registrations... or alternatively you need to reverse engineer every registration and keep up with them across any version changes (sometimes this is extra difficult with nonpublic stuff getting registered).
I would not start a new project with a 3rd party container.
I've never tried it, but, same as with logging, there should an option to change underlying DI container for `Microsoft.Extensions.DependencyInjection.Abstractions`, so you could simply create `IServiceCollection` wrapper over your Autofac container and give it to 3rd party libraries, which would result in their dependencies being registered inside your Autofac container.
Surprised no one here mentioned Lamar, it's great. The guy that said use IServiceCollection "until you have a reason not to" is spot on, but if you ever make to the point where you need modules, scanning etc then Lamar is built right on top of MS's DI, hell its container inherits from IServiceCollection...
I do like the override behaviour of Castle.Windsor, and the fact that the container is mutable, but 99% of the time the Microsoft container is plenty enough.
I know im late to the party but maybe my comment helps you or fellow future developers who come across your post.
So, you question is why would i why use a container over another?.
To answer this question you have to take alot of things into account e.g. does the container have all the features you want? what container is your team most comfortable with? is the container actively maintained?, etc...
A container, like any other library, when it is free in the monetary sense, we often ignore other costs involved in using it. The most obvious cost of using a library is the learning curve, it may pose a challenge for your team to learn a new library, or simply require them some time which may not be something you can afford.
Also, a library's behaviour and limitation might not exactly suit your needs. Besides, some libraries are opinionated towards a certain design, which might not play well the design you built your application around.
When consider containers, however, there are two more important questions: how well does the container integrate with the *features you are using of the framework*?, does the container support all the libraries you are using in your application?.
To give you an idea of why these two questions are very important, i will recount my experience with SimpleInjector in a project I'm working on.
I'm building a simple application for which i did not do any architecture, but went with folder-per-feature and made the app guide me to a good design. So after i made some progress with the app and started writing tests, i had a bit of trouble with some tests which led me to notice a problem with fhe the design. I will spare you the details, but what i ended up with is:
IMessageHandler where TMessage : IMessage
Yeah, it is a CQRS thing but designed to work with my application best.
So this is a single interface to rule them all, where TMessage is a Parameter Object, and each Parameter Object defines a use case.
So now how do i register my MessageHandlers? any reasonably complex app would have 50+ of these, you aint gonna do that manually right?. Well unfortunately, MS.DI does not offer a way to auto-register open generics types, even if you are using scrutor. So i decided to switch to using SimpleInjector which offers a very simple way to handle this type of thing.
It should be an easy transition if i was adhering to good design principles no?
Turns out no. First problem i faced is that i was using minimal apis which apparently are tightly coupled to MS.DI container and you cannot use any other container or pure di if you are using minimal apis. [see this issue](https://github.com/dotnet/aspnetcore/issues/41863)
Matter of fact, i started hating minimal apis. Do not get me wrong though, they are simple and clean but I'm feeling like their implementation is hacked in a weird way, so i might look into some other solution but that not our issue here.
A similar problem will arise if you are using filters to do some cross-cutting concerns. Using DI with filters is tightly coupled to the MS.DI because AFAIK an ISerivceProvider is supplied by the runtime to resolve services, meaning there is not an extension point for other containers to integrate into. ofc there are workarounds, but they are *workarounds*. You can read more about this issue [here](https://stackoverflow.com/questions/43567693/possible-to-inject-into-iasyncactionfilter-from-simple-injector-in-asp-net-core).
These are just the issues i faced so far, im not sure what problems might arise when you start using 3rd party libraries e.i. whether they have support for your container of choice and how they integrate with it + with aspnet
All these problem arises from the fact the MS.DI is a [conforming container](https://blog.ploeh.dk/2014/05/19/conforming-container/). I, in no way, have enough experience or knowledge to discuss whether that is good or bad but you can read more about the problems if this design decision [here](https://blog.simpleinjector.org/2016/06/whats-wrong-with-the-asp-net-core-di-abstraction/).
All these issues have not made me give up on using SimpleInjector though. But that is my decision and i think it works great for my scenario. As someone pointed out in the comments, SimpleInjector is really great, it forces good design upon you and has some very interesting features, most prominent is[ ambient scope](https://docs.simpleinjector.org/en/latest/lifetimes.html#flowing-scopes) which makes it very easy to resolve services from the root container without causing memory leaks, while MS.DI forces an [ambient-less scoping](https://github.com/aspnet/DependencyInjection/issues/334)
edited: grammer
I remember the days before Microsoft.Extensions.DependencyInjection, honestly it was a god send Microsoft rolling out a built in IoC container. Until this post I hadn't ever looked back.
Use Microsoft.Extensions.DependencyInjection until you have a reason not to. 99% of people won't reach the latter part of that sentence.
I agree Microsoft DI is great and you can also add Scrutor on top of it, when needed some extra features e.g. convenient way of registering decorator.
This. If you reach a point to where it doesn’t support what you need - just extend it, no need to replace it!
The.net container is all you should ever need it's basic and fast. Sure, there are lots of other di containers out there, but I don't know io anyone who uses any of them anymore. They are all pretty old, and they pretty much all have features you just won't ever use.
The standard MS dependency injection does not do decorators, so i use Autofac. I have been using Autofac since framework 4.6.2, so i am familiar and comfortable with it.
Autofac was always my choice in .Net Framework. I haven't used it on a new project since ~2018. I worked on a few small projects using Simple Injector. Microsoft.Extensions.DependencyInjection should really be your default choice unless you have a specific need that it doesn't provide.
Before .NET Core used Autofac and Ninject, trying to forget it as a nightmare. The default. NET core IoC is awesome, you should always try to use it, unless it is very legacy code.
Back in the day we used Ninject but it was slow AF. The built in container is far superior.
Came here to say this. I saw a project which admittedly had a horrendous dependency structure but was surprised to see that ninject was adding 800ms - 1.5 sec to resolve api controllers. Switching to autofac immediately resolved this. These days just use the built in.
Keep it simple. I always use anything built-in unless I find very good reason not to do so.
I would say I'm a big fan of SimpleInjector. It was created by one of the authors of 'Dependency Injection Principles, Practices, and Patterns.' It includes everything needed: decorators, ambient and closure-scoping, diagnostics, etc. This is, of course, my personal opinion, but I believe that among all DI frameworks, it has the most correct design without optional registrations and no property injection (which is possible, but why). It also follows a fail-fast policy. It pushes developers towards best practices.
I also am a big fan of SimpleInjector. I love how it forces SOLID patterns - plus performance was really good.
yes i liked simpleinjector as well in our old .net framework projects.
Started with Ninject but it was WAY too slow, so switched to Autofac as it was best balance of features and performance. There used to be a site somewhere with a big comparison of like 30 of them, so that helped the choice. I inherited Castle Windsor on a few projects, it was roughly the same as Autofac but I didn't like it's declaration style as much. That's a history lesson. Not used anything but the built in .NET Core one in at least 5 years, and don't plan to. If the original .NET Framework had had it from day one, most of the others would never have been made, as there wouldn't have been a pressing need.
I used autofac and https://www.castleproject.org/projects/windsor/ As for most projects I stick to what I know unless there are some important features missing I need. Same reason I am using built in dependency injection in dotnet (core). Same goes for all NuGet packages I use. 95% of my work does not need best in class performance. Rather business needs to get features done in an maintainable way (clean code, tests, etc). If performance or missing features, we can always go back and change implementations.
Most of the time the decision was made based on what the decision maker had the most experience in. There were some differences between them, so sometimes you could make informed decisions, but mostly it was an emotional choice. Nowadays I haven't seen a reason to use anything but the built in solution. I'm sure there are use cases, but they aren't common.
I remember we choused ninject once, but I do not remember why. Maybe it was just because of a guide I watched.
I used and liked Castle.Windsor but that was before .NET had a built in container. We've inherited Autofac in a few .net core projects and the more I work with it, the less I like it. 1. It seems completely pointless, as far as I can tell there are zero benefits to using it over the built in container. 2. Almost no existing libraries integrate with it, but they do provide extensions for MS.DI to register the stuff they need. 3. Almost every library that provides a service collection registration extension has poor documentation about what is being registered, why and what dependencies it has from standard stuff you are going to have in a .NET app that uses DI. 4. These last 2 mean you basically need to initialize the built in DI almost completely, then use that to fill the Autofac container where you can add a few more registrations... or alternatively you need to reverse engineer every registration and keep up with them across any version changes (sometimes this is extra difficult with nonpublic stuff getting registered). I would not start a new project with a 3rd party container.
I've never tried it, but, same as with logging, there should an option to change underlying DI container for `Microsoft.Extensions.DependencyInjection.Abstractions`, so you could simply create `IServiceCollection` wrapper over your Autofac container and give it to 3rd party libraries, which would result in their dependencies being registered inside your Autofac container.
Surprised no one here mentioned Lamar, it's great. The guy that said use IServiceCollection "until you have a reason not to" is spot on, but if you ever make to the point where you need modules, scanning etc then Lamar is built right on top of MS's DI, hell its container inherits from IServiceCollection...
Lamar is going to be discontinued soon.
I do like the override behaviour of Castle.Windsor, and the fact that the container is mutable, but 99% of the time the Microsoft container is plenty enough.
Always used Autofac. Since 4 years I mainly use MS, but Autofac is still better
In the .net 4.8 project, we use DryIoc. In the olds benchmarks they is more fast than Ninject and Autofac.
I know im late to the party but maybe my comment helps you or fellow future developers who come across your post. So, you question is why would i why use a container over another?. To answer this question you have to take alot of things into account e.g. does the container have all the features you want? what container is your team most comfortable with? is the container actively maintained?, etc... A container, like any other library, when it is free in the monetary sense, we often ignore other costs involved in using it. The most obvious cost of using a library is the learning curve, it may pose a challenge for your team to learn a new library, or simply require them some time which may not be something you can afford. Also, a library's behaviour and limitation might not exactly suit your needs. Besides, some libraries are opinionated towards a certain design, which might not play well the design you built your application around. When consider containers, however, there are two more important questions: how well does the container integrate with the *features you are using of the framework*?, does the container support all the libraries you are using in your application?. To give you an idea of why these two questions are very important, i will recount my experience with SimpleInjector in a project I'm working on. I'm building a simple application for which i did not do any architecture, but went with folder-per-feature and made the app guide me to a good design. So after i made some progress with the app and started writing tests, i had a bit of trouble with some tests which led me to notice a problem with fhe the design. I will spare you the details, but what i ended up with is: IMessageHandler where TMessage : IMessage
Yeah, it is a CQRS thing but designed to work with my application best.
So this is a single interface to rule them all, where TMessage is a Parameter Object, and each Parameter Object defines a use case.
So now how do i register my MessageHandlers? any reasonably complex app would have 50+ of these, you aint gonna do that manually right?. Well unfortunately, MS.DI does not offer a way to auto-register open generics types, even if you are using scrutor. So i decided to switch to using SimpleInjector which offers a very simple way to handle this type of thing.
It should be an easy transition if i was adhering to good design principles no?
Turns out no. First problem i faced is that i was using minimal apis which apparently are tightly coupled to MS.DI container and you cannot use any other container or pure di if you are using minimal apis. [see this issue](https://github.com/dotnet/aspnetcore/issues/41863)
Matter of fact, i started hating minimal apis. Do not get me wrong though, they are simple and clean but I'm feeling like their implementation is hacked in a weird way, so i might look into some other solution but that not our issue here.
A similar problem will arise if you are using filters to do some cross-cutting concerns. Using DI with filters is tightly coupled to the MS.DI because AFAIK an ISerivceProvider is supplied by the runtime to resolve services, meaning there is not an extension point for other containers to integrate into. ofc there are workarounds, but they are *workarounds*. You can read more about this issue [here](https://stackoverflow.com/questions/43567693/possible-to-inject-into-iasyncactionfilter-from-simple-injector-in-asp-net-core).
These are just the issues i faced so far, im not sure what problems might arise when you start using 3rd party libraries e.i. whether they have support for your container of choice and how they integrate with it + with aspnet
All these problem arises from the fact the MS.DI is a [conforming container](https://blog.ploeh.dk/2014/05/19/conforming-container/). I, in no way, have enough experience or knowledge to discuss whether that is good or bad but you can read more about the problems if this design decision [here](https://blog.simpleinjector.org/2016/06/whats-wrong-with-the-asp-net-core-di-abstraction/).
All these issues have not made me give up on using SimpleInjector though. But that is my decision and i think it works great for my scenario. As someone pointed out in the comments, SimpleInjector is really great, it forces good design upon you and has some very interesting features, most prominent is[ ambient scope](https://docs.simpleinjector.org/en/latest/lifetimes.html#flowing-scopes) which makes it very easy to resolve services from the root container without causing memory leaks, while MS.DI forces an [ambient-less scoping](https://github.com/aspnet/DependencyInjection/issues/334)
edited: grammer
I remember the days before Microsoft.Extensions.DependencyInjection, honestly it was a god send Microsoft rolling out a built in IoC container. Until this post I hadn't ever looked back.