I am currently migrating from .net4.6 which uses NInject modules. My target is to use .net6 core and its native DI. While doing so I came across a statement from NInject for which I am wondering if there is an equivalent for the same in .net6 native DI ?
this.Kernel.Bind(typeof(ICachePoolProvider<>)).To(typeof(CachePoolProvider<>));
Should I register for each type of ICachePoolProvider as shown below?
services.AddSingleton<ICachePoolProvider<string>,CachePoolProvider<string>);
services.AddSingleton<ICachePoolProvider<QueueClient>,CachePoolProvider<QueueClient>);
services.AddSingleton<ICachePoolProvider<NamespaceManager>,CachePoolProvider<NamespaceManager>);
I never used NInject but from your code I expect the method you are searching for is:
services.AddSingleton(typeof(ICachePoolProvider<>), typeof(CachePoolProvider<>));
You can find a good example of an IGenericRepository here
Related
I'm configuring DI container to be able to resolve several services inside my app.
If I would have used autofac, I would use modules from there to logically bundle registrations.
Does ASP.NET core framework has analogues for modules? How can I achieve that if I want?
Official doc on DI says:
Does that mean that I shouldn't be looking for module system anymore?
And if I have like 20-50 services, it's best to create an extension for each separate one?
AFAIK there is nothing comparable to autofac's modules registration in the core DI implementations.
You would have to implement it on your own, which should not become a really big deal.
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.
A would like to make my ASP.NET Core project could see only another library: Api, where I have interfaces. And another library makes wiring for interfaces and their implementation.
Instead of it Microsoft Dependency Injection Library proposes to make a wiring point right in the asp.net project. In this case this project will see both libraries: Api and ApiImpl. And it's not acceptable.
I wanna find a solution like Ninject, for example, does with modules.
A kind solution of this is here:
https://github.com/aspnet/DependencyInjection/issues/497
After updating our solution from SpecFlow1.9 to 2.0 and NUnit2.6.4 to 3.2.1 we get a SpecFlowException when the SpecFlow tests are executed with NCrunch
TechTalk.SpecFlow.SpecFlowException : The ScenarioContext.Current static accessor cannot
be used in multi-threaded execution. Try injecting the scenario context to the binding
class. See http://go.specflow.org/doc-multithreaded for details.
at TechTalk.SpecFlow.ScenarioContext.get_Current()
The solution the link http://go.specflow.org/doc-multithreaded in the exception text suggests only works when you use the build-in mini IoC of SpecFlow. However, we use NInject as IoC in our SpecFlow tests. Just wrapping the static field ScenarionContext.Current in a class and registering that class in a singleton context of course just moves the problem to another place.
Does anybody knows how to inject the ScenarionContext when NInject is used instead of the build-in IoC of SpecFlow?
SpecFlow now supports other containers via plugins for each container. Only one container can be used as it is injected into SpecFlows container. So if you use the Ninject plugin, then you can only use the Ninject plugin.
Unfortunately the developer who created the Ninject plugin did not publish it to NuGet so you'll have to build it yourself.
https://github.com/MattMcKinney/SpecFlow.Ninject
And you might want to ask him which license his plugin is using.
I understand some of the functionality of Ninject and have been able to use it for IoC.
When I go to add a reference to Ninject to a project in VS2010, using NuGet, I see other Ninject extensions in the list. Specifically Ninject.MVC3. Also on the Ninject website under extensions ( http://www.ninject.org/extensions.html ) I see Ninject.Web.Mvc.
If I am creating MVC3 applications do I need to use this extension of Ninject? Does my basic use of Ninject for IoC with classes/interfaces require anything beyond the standard library?
What is the difference between Ninject and Ninject.MVC3/Ninject.Web.Mvc in an MVC3 project?
ninject.web.mvc is a ninject (core) complement for the ASP MVC (3) applications. Basically - you should use it, when you want to use Ninject in an ASP MVC project.
From the documentation:
This extension allows integration between the Ninject core and ASP.NET
MVC projects. To use it, just make your HttpApplication (typically in
Global.asax.cs) extend NinjectHttpApplication:
MVC 3 extension contains the crucial methods to wire up the DI composition root into MVC application - it means that Ninject will be responsible for instantiating your controllers, that has dependencies on other components (Ninjects 'overrides' the use of DefaultControllerFactory which is only able to create controllers with parameterless constructors).
In the documentation there are mentioned two methods, how to do it: either extending the NinjectHttpApliaction in global.asax or using the NinjectWebCommon class inside the App_Start folder.
There is also ninject.web.common extension, which is required for ninject.web.mvc. It contains e.g. the definition of InRequestScope.