I recently updated ASP.NET MVC 3 app to Ninject 2.2.
Previously I had the following interface to implementation binding in my main app:
Bind(typeof(IMyInterface<>)).To(typeof(MyImplementation<>)).InRequestScope();
In addition, I had the following in a different assembly that was being loaded by my main app:
var arg = new ConstructorArgument("info", "something");
Bind<IMyInterface<MyClass>>().To<MyImplementation<BlogComment>>().WithParameter(arg);
This worked fine previously and the more specific implementation (the one with the argument) was being recognized. However, when I upgraded to Ninject 2.2, I received the following error:
Error activating IMyInterface{MyClass}
More than one matching bindings are available.
Activation path:
2) Injection of dependency IMyInterface{MyClass} into parameter myParam of constructor of type SomeOtherClass
1) Request for IMyInterface
Suggestions:
1) Ensure that you have defined a binding for IMyInterface{MyClass} only once.
What change was made from 2.0 to 2.2 that is causing this and is there a work around?
Ninject 2.2 ensures that only one matching bindings exists when resolving instances. 2.0 returned an instance of the first matching binding ignoring that there are others. But having multiple bindings if only one is requested reflects a bad configuration and can lead to hard to detect unintended behaviors.
But I see that there should be the possibility to overrule open generic bindings with more specific ones. I'll definitely look into it and it will either be added to a bugfix release or the next major release.
Related
I'm trying to go as native .NET as possible with a project I'm working on but the reference project I'm migrating has some Simple Injector registrations. Here's a line I'm stuck on
container.Register<IValidator<Foo>, FooValidator>();
container.Register<IValidator<Bar>, BarValidator>();
container.RegisterConditional(
typeof(IValidator<>),
typeof(ValidateNothingDecorator<>),
LifeStyle.Singleton,
c => !c.Handled);
This is from the Simple Injector documentation and I'm wondering if there's an equivalent way to do this on the built in .NET 6 IServiceCollection?
Although there is no equivalent for RegisterConditional in MS.DI, and I'd say that in many cases you're out of luck, in this particular case you are likely using the ValidateNothingDecorator<T> as a fallback in case no explicit (non-generic) registration exists. This can be done as follows in MS.DI:
services.AddTransient<IValidator<Foo>, FooValidator>();
services.AddTransient<IValidator<Bar>, BarValidator>();
// Register open-generic fallback
services.AddSingleton(typeof(IValidator<>), typeof(ValidateNothingDecorator<>));
In MS.DI a registration for an open-generic type always functions as fallback; in other words, if there exists an explicit registration for a specific closed version (e.g. IValidator<Foo>) of the given open-generic interface (e.g. IValidator<>), the closed version is selected.
This is not how it works with Simple Injector. In Simple Injector you explicitly have to specify the conditional registration is the fallback using the !c.Handled lambda. This design is chosen explicitly to make the registration process less implicit and less error prone. Using this design, it allows Simple Injector to validate the correctness of the registrations, because Simple Injector does not implicitly chose from multiple applicable registrations; it forces to you specify what you meant.
I'm a relatively new user of both Autofac and ASP.NET Core. I've recently ported a small project from a 'classic' ASP.NET WebAPI project to ASP.NET Core. I am having trouble with Autofac, specifically in registration of generic types.
This project uses a Command pattern, each command handler is a closed generic like
public class UpdateCustomerCommandHandler: ICommandHandler<UpdateCustomerCommand>
These command handlers are injected into the controllers like:
readonly private ICommandHandler<UpdateCustomerCommand> _updateCustomerCommand;
public ValuesController(ICommandHandler<UpdateCustomerCommand> updateCustomerCommand)
{
_updateCustomerCommand = updateCustomerCommand;
}
Autofac is configured (partially) as:
var builder = new ContainerBuilder();
var assemblies = AppDomain.CurrentDomain.GetAssemblies();
//This doesn't seem to be working as expected.
builder.RegisterAssemblyTypes(assemblies)
.As(t => t.GetInterfaces()
.Where(a => a.IsClosedTypeOf(typeof(ICommandHandler<>)))
.Select(a => new KeyedService("commandHandler", a)));
The above does not seem to be registering the generic as expected. If I use the below method for registration, it works well.
builder.RegisterType<UpdateCustomerCommandHandler>().As<ICommandHandler<UpdateCustomerCommand>>();
When I say "It doesn't work", what I mean is that when attempting to instantiate the controller, I get "InvalidOperationException: Unable to resolve service for type 'BusinessLogic.ICommandHandler`1[BusinessLogic.UpdateCustomerCommand]' while attempting to activate 'AutoFac_Test.Controllers.ValuesController'."
This worked well in the Full WebAPI version of this project, but not after recreating it in ASP.NET Core. To be clear, this was working perfectly well before porting to ASP.NET Core.
Here is a link to the code that I've used to recreate this issue:
https://dl.dropboxusercontent.com/u/185950/AutoFac_Test.zip
**** EDIT AFTER SOLUTION DISCOVERED ****
There was nothing in fact wrong with my Autofac configuration and certainly not Autofac itself. What had happened was that I had renamed the output of my dependent assemblies in an effort to make the assembly scanning stuff (replacing of AppDomain.CurrentDomain.GetAssemblies() more elegant, however I never modified the dependencies of the API project to reference the new assemblies. So Autofac was scanning the correctly loaded assemblies which happened to be the older versions, which did not contain the interfaces and implementations I expected...
Autofac has built-in support to register closed types of open-generic.
builder
.RegisterAssemblyTypes(ThisAssembly)
.AsClosedTypesOf(typeof(ICommandHandler<>));
This will scan your assembly, find types that close the open generic ICommandHandler<> interface, and register each of them against the closed generic interface they implement - in your case, ICommandHandler<UpdateCustomerCommand>.
What doesn't work in your example is that you associate a key to your services. Autofac doesn't look for the keyed version of your ICommandHandler<UpdateCustomerCommand> when trying to instantiate the ValuesController, which is why you get the exception.
Edit after QuietSeditionist's comment:
I'll try to elaborate a bit on the keyed vs. default services. The way you registered your handlers is by associating the commandHandler key to them.
This means that once the container is built, here's the only way you can resolve such a handler:
// container will look for a registration for ICommandHandler<UpdateCustomerCommand> associated with the "commandHandler" key
container.ResolveKeyed<ICommandHandler<UpdateCustomerCommand>>("commandHandler");
When instantiating ValuesController, Autofac doesn't look for a keyed registration of ICommandHandler<UpdateCustomerCommand>, because it wasn't asked to.
The equivalent code it's executing is - and you can try to run that code yourself to get the exception:
// BOOM!
container.Resolve<ICommandHandler<UpdateCustomerCommand>>();
The reason your second registration works is because you didn't key the service:
// No key
builder
.RegisterType<UpdateCustomerCommandHandler>()
.As<ICommandHandler<UpdateCustomerCommand>>();
// commandHandler key
builder
.RegisterType<UpdateCustomerCommandHandler>()
.Keyed<ICommandHandler<UpdateCustomerCommand>>("commandHandler");
But since you don't want to register all your handlers one by one, here's how to register them without keying them:
builder
.RegisterAssemblyTypes(ThisAssembly)
.AsClosedTypesOf(typeof(ICommandHandler<>));
/Edit
I can see two scenarios where keying services can be useful:
You have several types implementing the same interface and you want to inject different implementations in different services. Let's say, you register both SqlConnection and DB2Connection as IDbConnection. You then have 2 services, one which is supposed to target SQL Server, the other one DB2. If they both depend on IDbConnection, you want to make sure you inject the correct one in each service.
If you use decorators, the way registrations work is you define the services to which the decorators will apply by a key - the first example is self-explanatory
Because Google brings you to this page even when you're trying to manually register types, I thought that even though this doesn't answer the asked question, it would be useful for future visitors. So, if you want to manually register a generic type, you would use this format:
service.AddTransient(typeof(IThing<>), typeof(GenericThing<>));
or if there's no interface, then just:
service.AddTransient(typeof(GenericThing<>));
and for completeness, if you have a generic with multiple types:
services.AddTransient(typeof(GenericThing<,>));
I wonder what's going on here...
I just created a new, empty F# Console application in Visual Studio 2013 (using F# 3.1 and .NET 4, FSharp.Core Version 4.3.1.0) and added the Reactive Extensions Main Library using Nuget: Install-Package Rx-Main
Now check this out:
This works and the hovering over test shows val test: unit -> System.Reactive.Subjects.Subject<'a>. As expected. Then I added the new keyword.
Interesting. Does anybody know why adding the new keyword breaks the code? For reference, if you additionally specify the type parameter, it works:
I can't find a spec reference off-hand, but when using new explicit type args are required. You need to do:
let test() = new System.Reactive.Subjects.Subject<_>()
It appears to be a static class, and static classes cannot be newed up.
http://msdn.microsoft.com/en-us/library/system.reactive.subjects.subject%28v=vs.103%29.aspx
And to elaborate on your specific error message, it means there is public no constructor available that accepts 0 parameters. As far as I know, static classes only have private, parameterless constructors.
My question is really a repeat of an old question posted here:
Ninject 2.2 multiple bindings
It seems someone was going to deal with this back in 2011. Does anyone know if there is some way to turn off such warnings in Ninject? Or some other workaround?
EDIT
In response to #BatteryBackupUnit, here is my exact problem:
I have multiple libraries... and in my core library, I do something like this:
Find all assemblies referenced by the host application (including the host)
Find all types inheriting from IDependency from all those assemblies.
Automatically register all of those as transient
Then from another library (which may or may not be referenced by the host app), I have this:
Kernel.Bind<IDbContextFactory>().To<DbContextFactory>().InSingletonScope();
Here IDbContextFactory is also an IDependency, so it got loaded already by the core library and now I register it here but with a different scope (singleton).
From experience (and having tested it earlier) I know this is no problem in Autofac, but Ninject gives me that error message about having already registered it.
Ideally it would be better to just override any previous registrations... "cascade style" (for lack of a better phrase)..
Ninject does now support overriding open generic bindings with more specific ones.
For Example:
public interface IFoo<T> { }
public class Foo<T> : IFoo<T> { }
public class StringFoo : IFoo<string> {}
used like:
var kernel = new StandardKernel();
kernel.Bind(typeof(IFoo<>)).To(typeof(Foo<>));
kernel.Bind<IFoo<string>>().To<StringFoo>();
var intFooInstance = kernel.Get<IFoo<int>>();
var stringFooinstance = kernel.Get<IFoo<string>>();
Works.
However, if you're not talking about open generic bindings, ninject 3 still handles multi bindings the same as ninject 2.2.
In most scenarios you can work around this by using contextual bindings. Okay i would not exactly call it a workaround, i would call it good design.
In general this is described here: https://github.com/ninject/ninject/wiki/Contextual-Binding
A simple way would be to specify the binding using a name. This requires one binding for the specified one and allows only one, too.
See: https://github.com/ninject/ninject/wiki/Contextual-Binding#simple-constrained-resolution-named-bindings
It is also possible to define a "default" binding like .Bind<IFoo>().To<Foo>(); and special case bindings with the .When(...) syntax, like:
.Bind<IFoo>().To<SpecialFoo>().When(ctx => ...)
See https://github.com/ninject/ninject/wiki/Contextual-Binding#specifying-constraints-on-the-type-binding-using-arbitrary-elements-of-the-resolution-request-context
If you show us your concrete problem we might be able to provide a more concrete solution.
My original project is in Asp.net MVC 2.
I convert my project to MVC 3 without problem.
In the same time, I install the EntityFramework 4.2. Again without problem.
Were it's begin to be complicated is when I add the T4 Generate DBContext.
Thats create me the T4 properly and generate all my entity into his own "POCO Class". Thats perfect!.
When I Build my project, I Got about 400 error. Here is some example.
'mvn.Models.DBEntities' does not contain a definition for
'AddToLeaseConditionInfos' and no extension method
'AddToLeaseConditionInfos' accepting a first argument of type
'mvn.Models.DBEntities' could be found (are you missing a using
directive or an assembly reference?)
As you can see here, the context.AddToLeaseConditionInfos(objCondition); doesn't work anymore.
Same for the DeleteObject context method.
context.ConvertionUnits.DeleteObject(MyObjConvertionUnit);
Someone has an Idea.
Thanks a lot.
You previously used ObjectContext API and default code generator (or EntityObject T4 template) but now you are trying to use DbContext API with POCO DbContext T4 Generator. Those two are completely incompatible because they represent different API. You must use the same code generation approach as you used in EFv4 (which means upgrade will not give you almost any additional value) or you must rewrite your current data access code to use new API.