Dependency Injection Is Now Complete In .NET 8! 

The use case that's actually useful for this is providing multiple versions of your API. You decorate your services worth attributes that specify versions, you inject specific version based on the requested API version that was invoked.

Regarding naming the keys for injection, they should be named for their purpose, not for their implementation. Instead of "openweathermap" and "weatherapi" they should be "main" and "backup". That is the point of injecting interfaces as in the future you may decide to prefer weatherapi as you main service for example.

This feels suspiciously like the service locator antipattern. Also, it breaks separation of concerns somewhat, unless your concern is the fallback mechanism specifically. I'd create an IWeatherService implementation, FallbackWeatherService, or something, which would take two (or a list of) IWeatherServices and register that in the DI container.

This demonstrates how to get both the main and backup services for retrieving weather. But what I thought you were going to show is how to gracefully degrade to the backup when the main service is down; that is the more interesting problem here.

I would add one use case I see frequently that this solves more elegantly. We use a lot of Dapper here, and so our services regularly need an IDbConnection, but sometimes to two differrent databases (different connection strings). Because a service or repository class needs an IDbConnection, currently, we have to do a lot of extra work at the DI registration to figure out which IDbConnection we need for the service we're calling. With this, we can declare at the service's constructor which IDbConnection we need, or expect. Or at the DI registration, get the keyed service before calling the service's constructor.

Am I missing something as to why a "keyed" service with an alias is preferable to just explicitly registering the service by its own type when you want to request a *specific* instance? If not that, then as others mention, a factory that handles resolving the service for you is the smartest and most reliable solution. I dont really get why someone would even need something like this.

While interesting, I can't think of a use case for this. In a scenario like the one you've described, I feel a better solution would be to create a singleton wrapper class that takes in IEnumerable and cycles to the next service whenever a 500 is returned(or any other "cycle to next" conditions). That would allow setting up a variable amount of backup services without requiring the usage of keys.

Used to use Autofac back in the day, and while I understand adding this for completion, it's not been a feature I've missed. Having to annotate the dependency requires knowing the key at design time, which feels (to me) like it violates the idea of "inversion of control". When I've had a use case to use one of N implementations in the past, I've just registered a good old factory delegate that would hand me the registered service I needed based on the function parameter I passed in. Having said that, it does allow a neater method for creating decorators instead of using something like Scrutor or rolling your own decorator extensions.

if you hardcode a key when requiring a service through di then what is even the point? why not inject the service directly without an interface?

Another work-around is to inject a factory class that can resolve your dependency based on whatever key as well. This new approach would be a little cleaner though.

I genuinely hoped they will never bring it to default DI. It is quite an antipattern that breaks the whole point of using DI, which is explicitly about _not_ specifying desired implementation. Loose coupling goes straight out of the window with the "keyed DI" approach.

Back in the day Ninject has different approach for that. It was something like Bind().To().WhenInjectingInto(x => *filter*); //or WhenInjectingInto() And that was better, because you still manage your dependencies in startup, and not hardcoding some "alias" in your dependent class. As other comments mention, approach with Keyed/Named services is not any better than just binding different services to different (inherited) interfaces - dependent classes should know that they want, they should known name/key/alias.

I would really love for custom resolve methods. For example Would prefer to have a class A { A(ILogger logger){}} instead of class A { A(ILogger logger){}} and have it resolve depending on what type it targets

I really don't like the idea of having to modify some implementation in order for the dependency injection to work as expected. If I write a service to call some API, read from a db or do literally anything else, it shouldn't concern itself with how it is treated by some other part of the code. It should simply demand its dependencies and expose its functionality. And I don't need a DI container to implemenent any service itself. In this example I think I'd much rather have a third IWeatherService implementation which takes a number of implementations and contains the logic of when to choose which and fowards the interface calls and then just register that one. You could alternatively have a WeatherServiceResolver service that does the resolving and returns the chosen implementation. Although that would have the same issue as the keyed stuff. Anything that needs a weatherService, needs a weatherservice and shouldn't concern itself with the fact that I might wanna dynamically choose between different implementations, or that I use a DI container.

sweating from 20 degrees i would like to invite you to my house in Egypt 😅 20 is when i wear my winter clothes

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.

Thanks for mentioning Scrutor! For needs like caching, retries, etc., I've always manually wired up decorators, and it looks like Scrutor should make that much cleaner.

Not a fan of this feature - I don't like attributes and I reckon the enumerable route with a CanProcess() on the interface is cleaner and also easy to test. Guess there's situations it's useful like heavy service constructors, but I'd argue there's a design problem to consider? Always good to know though - thanks for sharing 🙂

Can you then inject Dictionary and pick your service out in the constructor? The attribute looks clean and all, but it looks like most of the benefit is lost if I have to hardcode the key

I do like the idea, but I personally wouldn't use it. Mainly because it tightly couples your code to the DI framework itself (in this case, Microsoft.Extensions.DependencyInjection.Abstractions). You can achieve pretty much the same thing, albeit not as elegantly, using the factory pattern.

Good honnestly it was the major issue I faced with D.I and as mentionned below I was using factory methods or some functions to provide the good implementation based on key. I reallly hope this will be implemented everywhere (I mean for Worker services, API, Blazor etc.)

A factory is the best of all worlds, in order to create any different type of instances. Thanks for the great presentation!

When you started talking about backup weather services I was thinking the DI would be able to understand what service is healthy as well and return it accordingly. That said, would be interesting if they could expose a interface to help how to resolve which service in case of multiple ones. I believe we would need a intermediary/wrapper Backup IWeatherService that gets both Weathers to property resolve which one to use. That would be an interesting example!

Thanks for the video! My only thing is that I wish you’d named the two keys and variables differently. I know it’s not the main focus on the video and it’s just an example in context, but ultimately people will, and do, use these videos as examples. Keying and registering services based on implementation is very leaky. Ultimately you have an interface and any concrete implementation could be used, the consuming code should not know about the implementation. I would generally prefer the use of an enum for example with the values of say “Primary”, “Fallback” etc, and then grab the primaryWeatherService and the fallbackWeatherService. They don’t care about implementation then. In this example, imagine you decided that the weatherApi was now your preferred api, you’d have two choices: one to swap the keys so that they no longer matches tbe implementation which is highly confusing, or go in and edit existing stable tested code to get it to use the weather one first and fallback to open weather - violating the open/closed principle. Using the generic naming all you’d need to do is, in the application root, switch the enum values around so Fallback is now Primary, and then that will be used as the primary, the assignment still makes sense, and we haven’t had to edit lots of code.

Today we handle this by having an interface that all of our implementations use, one of which is a public enum value. Then our services that might need one or the other request an IEnumerable from Dependency Injection, and then in their constructor pick the one they need. It will be nice being able to do this natively!

If you're looking for fail-over then I would expect the IEnumerable would have been a better solution. You try the first item and if it fails you move to the next. Doing the Keyed services you have to know ahead of time all the different services that were registered.

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.

Personally, I liked the fact that they didn’t implement this feature. If you’re going to bind to something concrete you might as well just bind to the concrete type, rather than use a key to bind an interface that binds to a specific type. This just seems backwards to me. Thanks for sharing though.

I used to like the autofac keyed service. But... resolving one implemention is part of the application logic, so it should not be part of the container. In that case, I prefer to use a factory so I'm explicit about resolving. Sometimes the factory is as simple as a key, so granted: factory might be overkill... but more often than not logic creeps in, and that's when factory is the right approach. You really don't want to let app logic creep in the DI setup, especially because it's harder to unit-test. Think refactor cost and risk: if not covered by a unit test you might not dare to refactor, so you're stuck in legacy code, just because you chose to use a fancy feature at some point.

"I wanna know your thoughts on the topic." Me: ... FINALLY!

In the context of my daily work, we solved this from a business perspective and never need two have multiple service suppliers for the same piece of data. 1. Make sure that our service supplier is not just running the service on one server (can be done via SLA or contract discussion) 2. Make sure that our service supplier has a SLA which guarantee a level of up time and performance time that is acceptable for us As our service suppliers are mainly fairly big boys in their field, we haven't really seen the need to plugin an alternative supplier up to now. Some times their system may go down, but that is within their SLA and our SLA, so it is something can be tolerated. Multiple suppliers always trigger data consistency and its own maintenance issues. So I feel that it is better to be handled by business perspective.

I needed this feature always. And now I use factories or implement my version of keyed wrapper. In new implementation I don't like attributes, in my opinion it should be configurable without attributes. And fully agree about decorators and convention.

@nickchapsas Don't you couple your method implementation, to a specific service implementation that way, which defeats the purpose of IoC? Keyed Service seems like a step backwards to me. For such usecases I'd prefer the "inject IWeatherServiceFactory" approach, and put the service selection logic into the factory, instead of relying on a DI-Container feature.

Hooray. Been using that for years in autofac. Used a factory recently to acheive that in one project. Nice to have it there now though

I would add that this is a component or plug-in architecture. My preference is to have an attribute on the interface which provides the "key" differentiator. Concrete classes would then define the key rather than the class key provided during registration with the IOC container. Then do ienumerable of the interface in constructor, and in code select the preferred implementation based on business logic.

Complete my foot! Wow they still havent implemented: - decorator pattern - interceptors - named instances Amazing how behind .NET DI is in 2023

Probably, the title is wrong. It should be called "DI-Container is now complete..." since Dependency Injection does not require a DI Container

Great improvement, now I can replace my own written workaround with that :-)

IDK, I used to intuitively tend to solutions that had keyed registed services, but it never really felt right. The whole point of interfaces is that the dependency is on the service, and the implementation doesn't matter. But if the client needs to pick which registered service is used, doesn't it technically make it a different service? I started using this other methode. It's fair to call it boilerplating, but I wouldn't call it a workaround: just make an empty interface for every named service and have it extend the original interface. No magic strings, no assembly scanners and you get exactly the service that you need, using regular DI.

Pro: no interface inflation; Con: magic strings. I guess whether or not to use it depends on the use case.

What about creating two interfaces IWeatherApiService and IOpenWeatherMapService, both inheriting IWeatherService? If you have to specify the key where you require the service, it looks the same to me.

Can't think of any use case for this feature but thanks for sharing

Hi! Don't understand the reason to bind two impl for one interface and then resolve by key. For me it's look like missing L from SOLID.

I can not find a good case where i could use this feature for any of my projects now or in the past. I feel itching that we are to spread constant strings around (looks "meh" as for me no matter how you wrap it...) As for me, I'd better inject some factory that relies on some non static (e.g config) props for resolving stuff I need. As other comments suggest. But maybe I just don't yet faced a case when I would need it...

Finally! It took a while though but hurray.

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.

I would register the OpenWeatherMapService without a name, and the fallback one with "fallback". The OpenWeatherMapService would have to be registered last so its made the default by the IoC Container. Depending on the use case I would just resolve an IEnumerable and use the data of the first one that works.

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.😂

What perfect timing for this. I have a situation that out came up that this fits perfectly. However, I'd like to know what the best way to do this in .NET 6 is (without using AutoFac).

I was really hoping it was interceptors. It's really nice being able to add logging to things without having to pepper my code with log statements everywhere. That's the one feature I'm still waiting for.

This feels like a very complicated way to have interfaces, but work around them. Also, this looks like it would make for messy unit testing.

This does not seem very useful to me, since the key is hardcoded into the injection site. What would be preferable is logic to determine. I have worked on a system with "tenants", where tenants may have their own services. (This was for an insurance company, where each 'tenant' had their own policy system, so we needed to inject services depending on who was calling.) We were able to achieve this with a non-default container, but I don't remember which one it was. EDIT: It was "autofac" I think?

Yeah, for me is great news, generally, I'm always against adding big libraries to projects, especially when they have native support, less dependence is better for all of us (I'm talking about programming only 😅)

Wow, finally, I've been waiting for something like that for ages! It always bothered me that you can't use interfaces as they were originally designed to be used to in the Microsoft's dependency injection.

It really feels like the consumer knows too much about the dependency using this feature. As other have pointed out, there are better ways. I would like to see a real work production app that would use this. To me just have two interfaces that implement the 'base' interface and register those. Seems like a cleaner implementation.

Its really nice one, I request you to have a session on IAsyncEnumerable implementation and usage. Thanks for sharing the knowledge with us.

For me, this features is an absolute minimum requirement for a IoC container (along with a few other features the built-in IoC is still missing), I just added autofac to my projects as soon as I had the requirement for it.

The one feature I didn’t like was if you need an inline resolution you have to pass the IKeyedServiceProvider through the constructor verse having a way to get a resolving class that is by the interface so you can see in constructor what your dependencies are

I don't like service being dependent on DI container, especially these Attributes, it doesn't allow you to reuse a service using another implementation of interface. Also, it misses "rules" functionality comparing to DryIoc, for my use case - I want to reuse a service using specific key, and I want all nested services to be resolved using that key, doesn't look like it will be possible to do.

I have been using Autofac for this until NET 8. Grand! One less external dependency.

Is there any compile-time protection from mistyping the key?

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.

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?

About time, this essentially means that other DI providers like Autofac are basically obsolete since they only provided keyed services and some very advanced and exotic use cases like interceptors. But right now, for 99% of my apps, I wouldn't really need these capabilities anymore. Happy to see this in MSDI finally.

Does it support injecting multiple implementations as IEnumerable of the same key if several is registered with that key? Or keys must be unique?

You have good and informative videos, but you should seriously consider a slower cadence. As for this example in particular, it seems to break SoC (antipattern), has some naming issues (implementation rather than purpose), and depends on hard-coding.

I still don't understand the benefits of those Singleton Services over static variables you can reference.

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

This does not seem to do the same as injecting IEnumerable and filter since you cannot chose on runtime what implementation you want. I often have an Enum wnd different implementation depending on that. Means I need a Func to get the according service during runtime because it may comes our of the configuration or so. Its one Step late.

so the default is always the last registered? kinda wish there was a way to register, and say "this is the default" that way the default is not position dependent

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 with the keys.

Doesn't this violate the open-close principle? The dependent class now needs to statically refer to its dependency (albeit through the key alias). If you wanted to change the behavior of the dependent, you'd have to come in here and modify it. I think in a real scenario, you would not be using the key to identify specific concrete implementations, but rather "flavors" of implementations, like "cached" or "uncached" as you mentioned.

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

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

My (brain) at 2:38: "the real f__cking API" (that couldn't be right, rewind 10s) "the real bucking API" (Is that UK slang?, rewind 10s) "the real backing API" (Oh. I'm an idiot)

IMHO the "key" dependency is the wrong way around. It should be a registration concern, not the resolved. Same issue as base classes having to know about their derived. Worked successful with Unity DI container for years, the resolved instance never had to worry about which implementation it got. Think about conditionally adding a cache wrapper. By using an attribute I have effectively decided at compile time which one I get.. or I change the registration to match what is being requested.. which basically defeats the purpose. Can I use the keyname when I resolve, like with ActivatorUtilities, or registration factory lambda? Will resolving IEnumerable retrieve all the instances, both non-keyed and keyed. If I resolve without the key attribute, will the existing behavior apply that includes key-ed registrations in the last-in best-dressed eval? The biggest issue I have with MS's ServiceCollection is the lack of ability to use a factory with an open generic. You can't get the type(s) being used to resolve. Not common, but very handy when the need arises.

Resolving a service by name.... isn't that Service Locator - usually considered an anti-pattern?

I'm going to stick with AutoFac. I've used it for many years, without issues, and don't see any compelling reason to change. The ultimate king for me is performance, and not just at a theoretical level. I'd need to see a practical implementation where it actually makes a big difference in a real world scenario.

Strings passed to Attributes must be constants, so how is this different from just injecting the concrete type?

async is a pretty big thing missing

MSDI was always meant to be a simple DI interface, which you can easily override with your own implementation, so you can easily use any container you want. I'm worried that if they add more and more features to it, it will be harder to replace it or some features will be missing with some implementations. It would defy the whole reason to create MSDI

I'm not sure if I get it. If we are acquiring the given service by its actual type then why are we trying to register them by the interfaces they implements.

thanks for the video

I love this change. 😊

I prefer to work with keyed services when an entity or contract has a discriminator

Well, 10 years later we might get brand new features like dependency validation and captive dependency check)

Good one, thanks :)

I don't get the usefulness. I want my interfaces to hide my implementation, so why add an attribute (also yuck) to then request a specific implementation? I'd much rather just inject the concrete type, or even better, just have a more specific interface. Another commenter mentioned that this could be for purpose rather than implementation; fine, but is this really the way to solve that problem? You could have a service dedicated to providing instances dynamically based on purpose rather than tie purpose to a compile-time decision. What's the use case for this?

Castle Windsor DI have that for at least a decade! 😌

To be fair, I dislike built-in container simply because Ninject feels nicer to use in any dotnet application, even console one. It is a one-liner for the initialization part, and it is easy to split code with modules

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?

How about the existing NamedSingelton?

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

Just bought your new course but it doesnt work :( Only white screen after starting it

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

some devs would get amazed by this rather than writing their own factory implementation which is a headscratcher for a few.

Goodbye Scrutor. It was a pleasure ❤

This was still achievable before .net 8 using factory lambda expression

Top feature. Sad that our architects not good with di and force app developers to use statics or other self written approaches.