The .NET dependency injection methods you are not using 

Don't worry I learned it the hard way too 😂

Could you please recommend any materials regarding multi-tenant systems? I've worked with one too little to really understand how to deal with stuff in this case.

It would be easier indeed but my reasoning was that more people have seen DI in the context of an API than a Console app

From what I’ve seen with Nick is he uses nsubstitute and tries to avoid using registration in the test project. I’ve tried where I create a bootstrapper in a test project but I think we have created objects with too many dependencies. We are working on making smaller classes to try to avoid this headache

As nick mentioned, all the `services.AddScoped();` things are just extension methods to add things to a service collection, which is essentially a dictionary. You can simply use it as a dictionary and use var serviceDescriptor = services.FirstOrDefault(descriptor => descriptor.ServiceType == typeof(IService)); services.Remove(serviceDescriptor);

Couldn't find any no matter how hard I looked

You can make interfaces that inherit IService and use that instead of your factory, if you really need to have them share a same interface.

@@sergiofonseca2285 That's what I basically do right now. I have a factory that gets `IService` enumerable from MSDI and then, based on the value in the header I return specific instance which is really annoying when you have more cases of that kind. I ended up making up a generic factory because the real difference there to return a proper `IService` is determined by the header value

As far as I know the default container doesn't have that capability. The keyword you're looking for is Assembly scanning. There's this other video by Nick explaining it: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-_YkvFQ1-Lt0.html

@simple gameplay - as @Foam says, the built in container does not implement assembly scanning, and for very good reasons: MS wanted to keep it lightweight and fast and they've succeeded by and large. However there are libraries that will do what you want. Certainly AutoFac does (and I'm sure other DI containers), but that means you have to use AutoFac (or other) instead of the built in container, which may be fine for you, but personally I use Scrutor on top of the built in container which offers some very powerful options for assembly scanning that you can use to treat different parts of your project in different ways. You might want all interfaces in a specific namespace to be singletons, for example, or to have different duplicate behaviour. Scrutor allows you to use selectors to do this sort of thing. Some caveats: It's very powerful and can make your DI registrations very clean, but it can be very easy to over-complicate things with selectors and whatnot and to someone coming in cold, it can look like a lot of magic so be aware that you might want to add comments, but if you have too many then you're probably doing it wrong. Also, with manual registration you can often catch missing registrations at startup when running in your development environment (try commenting out a registration and you will see that when you try and run your project you will get an exception telling you a service can't be resolved), but with a library like Scrutor, although you can often add services and they just get registered automagically using whatever default behaviour you have defined, it is possible for services to get missed if you have complicated rules set up, and this will not manifest until runtime when something tries to use that service and you may have already deployed to production(or at least your QA/automated testing might fail and then you have to debug and find out why which costs time). Note that in both cases it is possible to compile and deploy your application with missing registrations and in both cases it will fail at runtime when you first try and use your app, but in general you do have a better chance of catching these problems with manual registration and running your app in debug to check things are working before committing code. Like all libraries designed to take away some drudge work, there are positives and negatives and it's up to you to understand those and weigh them up against your use case before using any library (just look at the love/hate relationship the community has with AutoMapper, for instance). One use case really springs to mind and that's serverless applications: Be very mindful of implications on cold start times with any library that does things automagically. But use it wisely and Scrutor can be a very powerful tool that means you don't have to have reams and reams of DI registration code in your startup. It's a few years old now, but Andrew Lock has a great primer blog post on using Scrutor. Happy coding!

Yeah, I agree. Most DI containers allow you to have named registrations. It's too bad MS do not support those, especially as Microsoft.Extensions.DependencyInjection.Abstractions is now the main abstraction over DI containers...

Could you clarify what you mean by this, and in what use case it would be helpful? It sounds like you want to do addX and addX, but then have some means of specifying at GetService time which of S1 or S2 you want it to return. Is that correct? If so, I believe that can easily be worked around. For example, to ensure that a given interface returns S1, you can just 1) define a tag interface ITag, 2) register the desired service as itself (e.g. addX), and then 3) register the tag service with a factory lambda that fetches the S1 service (addX services.GetService()). That way, S1 and S2 are still bound to the original IService, but you now also can request S1 via ITag AND keep consuming classes from having any direct dependency on the concrete S1 implementation of IService.

@@MrEnvisioner There's no way to do it the easy way without any extra effort or hacks. But quite often one interface has many implementations.

I believe the problem here is not with the features of the library, but with desire to misuse it. Look at this from this perspective: If a class depends on a specific implementation (e.g on a ColourPrinter), then it's a mistake to have it accept a generalized abstraction (IPrinter). If it truly depended on abstraction (IPrinter), it shouldn't care which implementation it got (MonochromePrinter, NullPrinter, PdfPrinter). If it cares (it must be a ColourPrinter), then perhaps you could improve your interfaces to reflect that (IColorPrinter inheriting from IPrinter and make class depend on that instead of IPrinter).

Like Robert above me said, this has bad design smell all over it for me. If you want a specific implementation, than register it as a different interface and resolve for that, or resolve for the implementation directly. If you are trying to resolve for a service and you care about the implementation that you get, than you should be changing what you’re resolving for. There’s a reason why the Options extensions support named options/config, but the DependencyInjection extensions don’t support named services. It’s obviously doable. But the former makes sense, the latter doesn’t.

and i know it's not good behavior to write, but it also wrong be say not singleton.

Multiple reasons. Decoration, conditional resolution, pipelines just to name a few

I'm using a Logitech MX Keys

@@nickchapsas I am impressed of your typing speed !

I sure am 😀

Nice explanation, I've already had problems injecting same type twice! Thanks!

I have implemented my own named instances for my stuff. Maybe that's a good idea for a video actually

@@nickchapsas Yes would really appreciate it. I was about ask this in the comment

They do only if there is something actually do update them on. For example my Minimal API course will have an update in .NET 7 because of the new features. There is nothing in Unit testing or dependency injection that is changing in .net 7 so no planned changes there

Bundles are logical groupings. There is no bundle that makes sense to have all the courses. When my Integration Testing course is out, the Essentials Bundle will go away and the two testing courses will become a new bundle

@@nickchapsas I see what you're saying. Maybe later when you have a dozen or so series, a kind of All Pass will make sense. Anyway, considering all the great free content you've made, I won't feel bad about buying any or all of the series you've made so far at their current price point.

It's very useful for plugin interfaces. At the moment I've got some code that needs to pass data on to similar APIs hosted at different third parties - I need to choose the API at runtime based on the content of my data. My library project for interacting with those contains * ISpecificExternalApi that exposes the relevant function on the API at an abstract level, and a name field * An ISpecificExternalApi implementation for each API type * IExternalApi interface that has the same function, but with an extra parameter for the "key" that decides which API name to use * An implementation of IExternalApi that has IEnumerable injected, logic for selecting an API from that list and proxies the calls * An extension method .AddExternalApis(this ServiceCollection) that adds all the ISpecificExternalApi implementations and the IExternalApi This way my library is easy to use - just call services.AddExternalApis() in the service startup, and add IExternalApi as a dependency in my consuming code. If I need to add more implementations of the API, I only need to update the library creating the implementation of ISpecificExternalApi and the key used in the data. No need to update every place that calls it.

@@HaralHeisto interesting. I haven't delt with calling multiple APIs passing the same data. I guess you could use it as a messaging center as well. If you want a notification in Microsoft Teams, Slack, Email, Text Message, etc, you could do it that way as well.

​@@DerekWelton You could, but be aware that opens you up to complications around partial success. I'm using that library in a messagebus based application - if an API call fails the transaction is failed and retries later. If you're doing a broadcast to multiple systems, you'd need to add another layer of message queue behind your routing class. Given that, it's probably simpler to just have multiple subscribers on your SendNotification message and have them decide if they need to action the message or not.

Like Haral answered to Derek Welton who asked the same thing earlier; he is giving a plugin example. I am using it in a system where my users are able to ship packages. Now we can ship with three, not to be named providers. At runtime the user gets to select which one to use. The solution is to have multiple implementations (concrete types) that all implement IShippingProvider. I will get a list of all of the registered types that implement IShippingProvider. Now I offer the user to select one. Then the code will just assemble the shipment data, with types that are also 'mine'. Then it calls a method that all of these concrete types implement CreateShipment(IShipmentData data); If I need to support a fourth one... I will just start a new library, add a new class ShippingProviderFour : IShippingProvider { ... }. Obviously test it.. but can then just drop that dll there. Restart and the thing gets loaded and registered automatically and the fourth options shows up in the dropdown.

@@paulkoopmans4620 That makes a lot of sense, thank you!

Ha! I forgot to mention that but all of them break the usualy "Try-out-return bool" patteron by just returning void and nothing else. You can't know if it was added or not

JetBrains Rider

It is yes. My latest aws lambda video touches on that

@@nickchapsas Thanks, I will check out more of the videos. :-)

@@nickchapsas Which video? The rest api? is it available with the "function" type of lambda?

Because it would be very bad for me if I wanted to actually make a profit

@@nickchapsas With the quality of your content you will easily reach hundreds of thousands student in Udemy for sure and will be much for affordable and accessible for everyone when they have sales 😀 You are the only DotNet professional I've seen giving advance turorial.

@@err_0-5rZ Udemy doesn't work for people that already have na audience of their own. Tim Corey has tried it and he said he lost 30k on publishing a course there. The main problem is regional pricing.

@@nickchapsas Sad to hear that, well anyway, I will just purchase your course in your website instead if that's the case

A ServiceDescriptor also takes a factory method, you'd have to pass TService and the factory method. This also works for Add and TryAdd. This way, you'd still simply inject TService and your factory method will be called to decide what implementation to inject. You can also just make a factory service , inject that and call something like .Create on it

@@Vinoyl Yes, this. Or add a tag interface to the desired implementation and register is alone using the tag interface. Or, if you can't modify the definition of the class, add a tag interface and bind to it a factory lambda that returns the desired instance.

@@Vinoyl Can you please elaborate more?

This part is mentioned in the course yeah

@@nickchapsas amazing, coz I have the course but i did not start it yet

Lombok. The library that exists because Java is terrible. Spring boot. The framework hat exists because Java EE was terrible. Spring boot's DI. Because your classes should know how they are supposed to be registered. Nah, thanks I'll never go back to that.

can you be more specific? :) You mean to ask why one would register multiple concrete types implementing the same interface (service)? search for/look at answers to Clemens's and Derek Welton's question

If you're looking for something you will be able to use in the real .NET world right away, then yeah