Develop Reference

Contextual Binding in .NET Core 2.2 DI Container?

In .NET framework, you can use Ninject to achieve contextual binding.
So for example:
Bind<IWarrior>().To<Samurai>().WhenInjectedInto(typeof(OnLandAttack));
Bind<IWarrior>().To<SpecialNinja>().WhenInjectedInto(typeof(AmphibiousAttack));
This means you can inject different concrete implementations depending on what you're injecting into.
I cannot see any method to achieve the same thing in .NET Core 2.2 - is this not possible, or does it just require a bunch of extra configuration?
Example code from the Ninject site

I had a need for something like this and ended up creating a NuGet package for it: https://www.nuget.org/packages/ServiceProviderContextualBinding/
Usage looks like this:
services.AddSingleton<IService, DefaultService>();
services.AddSingleton<ReplacementService>();
services.WithReplacement<IService, ReplacementService>()
.AddSingleton<Consumer>();
This package is basically a facade over the ActivatorUtilities.CreateInstance method, which is part of the MS DI code.

DI using Ninject

I am confused in DI. I have seen lot of articles that explains DI can be implemented using constructor and some articles mentioned DI using ninject. So I am not able to understand the use of ninject. if ninject is not there then also the code will work. Can you please explain what will the advantage of using ninject.

Quoting Darin Dimitrov
What does using Ninject provide for me that I can't do by just
following basic principals of loose coupling?
Fewer lines of code in the Composition Root
A standard container for handling your object lifetimes
Many plugins for injection in specific contexts such as classic WebForms, ASP.NET MVC, ASP.NET Web API
Possibility to automatically dispose your IDIsposable objects
...
All things that you should be handling manually otherwise. This being said, the DI framework is of little importance. It should be fast and offer the specific features you need for your application. But the DI framework should absolutely in no way influence the way you are designing your code and the different layers in your application in a loosely coupled manner (programming against interfaces and abstract classes to weaken the coupling between the different layers of your application).
So think of the DI framework as something that intervenes only in the Composition Root of your application and as a framework that you could replace in a blink of an eye with a different framework or even manually handling your object lifetimes.
For example the code you have shown in your question is very bad as it ties your layers to a specific DI framework. This [Inject] attribute over there is like a cancer. It means that your application code relies on a specific DI framework.
Also i suggest you read this book.

Is it wrong to register a 3rd party container with IServiceCollection in AspnetCore

A little background: I began to incorporate FluentValidation in an AspnetCore application where I use SimpleInjector as my DI of choice. According to the aspnet docs
"The ConfigureServices method typically returns void, but if its
signature is changed to return IServiceProvider, a different container
can be configured and returned"
This is all well a nice until I realized I needed to configure services that were not mine, which is why the example uses containerBuilder.Populate(services); i imagine. The nice thing about FluentValidationis I can created my own IValidatorFactory to resolve my validators (which is where my problem came from because my validators were registered with SimpleInjector, not the default container which thought I had none). I figured I could get around this headache by registering SimpleInjector's container with the IServiceCollection and inject that into my IValidatorFactory as the IServiceProvider instead of returning the container in the ConfigureServices method. Seems like it all works as a hack, but is this the way to go? Are there other ways besides the aspnet docs wiki?
references: https://github.com/JeremySkinner/FluentValidation/blob/master/src/FluentValidation.AspNetCore/ServiceProviderValidatorFactory.cs
https://docs.asp.net/en/latest/fundamentals/dependency-injection.html

There are fundamental incompatibilities between Simple Injector and the ASP.NET Core DI abstraction (i.e. incompatibilities that can't be solved) and many problems in general with the abstraction that Microsoft proposed.
Because of this our official advice is to:
Refrain from using a self-developed or 3rd party provided adapter for the .NET Core DI abstraction. Isolate the registration of application components from the framework and 3rd party components. Pursue a SOLID way of working and allow your application registrations to be verified and diagnosed by Simple Injector, without concern for incompatibilities with the framework and 3rd party components.
You can read in detail here how you should work with ASP.NET Core when it comes to using a 3rd party container.

MVC 5 DI with Web API 2 DI--how should dependency registrations be structured?

I'm creating an MVC 5 site with Web API 2 functionality inside it as well and I'm wondering how I should work with the fact that ASP.NET uses 2 different resolver instances for resolving MVC controllers and ApiControllers.
I found this article that explains how to configure the resolution, but it looks like it uses 2 separate container instances and doesn't explain how to register dependencies for each. It's just like "do your registration here."
Following the 2-container example, I was tempted to set up the app so that the Web API container only has Web API dependencies and the MVC container only has mvc controller dependencies, but I feel like in the situation where a component is used for both, having a subset of items used in both containers would be too much work to maintain correctly.
Is it okay to just have all of the dependencies installed in each container? Or is it better to use the same container in each resolver?
Edit: I'm not using Unity so I'm writing a resolver class to wrap Windsor. I'm considering having my resolver implement both interfaces and just assigning the same instance as the different resolvers as well.

C# Windsor Castle with ASP.Net Web forms - How to Resolving Business Class Library

I'm starting to use the Windsor Castle IoC container. The web app is ASP.Net Web forms, and there is a class library of business objects that I'm trying to add DI to.
I am initializing the Windsor Container in the Global.asax Application_Start method. I really will only want the container to be used in the Business Class library. The Class library doesn't know about the web application. It's in a different project.
What is the preferred way to initialize and resolve objects in this scenario?

i don't think you should use a DI container in your BL. this is the whole point with DI. object composition can be done in a variety of ways and this is determined in the composition root of your application. your composition root is not in your BL therefore the BL should have no reference to Castle Windsor. your composition root (the place where the objects are actually composed, where dependencies are actually resolved) is your web application project. it is there that you should decide how to compose your object graph: use Windsor, another container or poor man's DI.
also, creating the composition root in a web forms app is a little tricky. you can read more about this in 'Dependency injection in .net' by Mark Seemann p224-p230