Dependency Injection Is Now Complete In .NET 8!

Its still missing property injection. Now that we have required properties, this feature is begging to be here.

Is/will there be a way to get TService[] allOtherImplementations without having to know the keys of other services registered under the same interface? Or Dictionary<string,TService> with the keys.

Caution with usage of keyed/named services, because it might introduce code smells. If the services are meant for redundancy, they are necessarily semantically equivalent. Hence it should be transparent for the consumer and the consuming code should not be forced to chose. To implement redundancy is a separate, technical concern. Create some wrapper with polly for instance, but keep the consuming business code clean!
However, if the named services convey different semantics, they should probably be distinguishable not only by some config name, but rather by an interface.
Also note, that the naming introduces an dependency, that DI is exactly meant to overcome! "Ask for a fulfilling service and don't care for the implementation!"
I confess that I felt like reaching out (in rare occasions) in the past for named services in DI, but meanwhile when running into this it rather makes me think twice.

My use case for this feature was for my chatbot project. I have two background services that implement IChatClient interface, and a key was coming into play when I wanted to post a message as a response to a comand coming from one of them. Then I used a key again to post an announcement to Discord when a stream goes live. I built my own implementation on top of ServiceCollection for things to be more dynamic, and also to explore this concept. It has its uses, but things can get a little convoluted and tightly coupled quite fast

Hey, could you not solve your singleton problem with generic interfaces? For example IWeatherService<OpenWeatherMapService> and IWeatherService<WeatherApiService>

i always used factories for this, if im understanding this correctly this would be just like having a factory except you dont have to create the instances yourself?

Isn’t the whole point of DI to remove dependency on specific implementations? By adding keys/removing interfaces we are making the code tightly bound.

This feature also existed in Unity DI (still Microsoft), and it was way over abused. I prefer to avoid this kind of scenario by adding an identifier to the interface I'm registering that is implemented by the implementation class. In this way, I can do the factory filter in my code... without relying on the DI to do it for me.

You know you're screwed when you notice that over 400 instances are name registered in just a simple application.😂

I wish they never added this. This breaks IoC as you are asking for specific implementation at compile time. The IEnumerable way which you call "mehh.." at least you can guard and key of at runtime. So you can pick services by config / from db . Id rather they did the DI by convention so we dont have to use Scrutor

What's wrong with facading the interface?

The less 3rd party dependencies the better. Especially if its native C#, since importing 3rd party dlls etc. into cross platform apps can be difficult still (Unity3d).
I feel like the native libraries are part of what makes languages take off. Python comes to mind, even though honestly I never fully touched it, but everyone says it can do anything. I also recall some unix libraries having that same adoption rate when they became a jack of all trades.

Finally

Could this be used in conjunction with featureflagging, where you would use versioning or some other functionality to choose which service to use?

thanks and, you didn't show how it would automatically resolve services at runtime when say for example the first service fails.

You could do this before using a generic in the interface like an enum. I think it's more advantageous if you could use the key inside the ctor so you can use do something like use a database value for the key to dynamical change it.

IMO, DI needs to either die or spit out a compiler error if a DI dependency isn't registered, but given that this is just a library and not a language feature, I'm not holding my breath for that compiler error.

Hi, NativeAOT work for window form?

Some people have somewhat pointed at this with the references to the similarity of the Service Locator Pattern/Antipattern, but if we are just looking things up by "magic string", then what's the point? Hierarchical interfaces with automatic registration helpers would be better, because then you could just ask for an IWeatherService and IFallbackWeatherService and not have the potential of copy-paste errors in magic strings. If you want configurability, you'd probably make an IWeatherServiceFactory which takes the IEnumerable<IWeatherService> and reads the config to return the desired IWeatherService or fallback given the situation.

Pls do not use this feature.
Anytime you run into that is similar to what is described in this video, a factory and strategy will work just fine.