Produces exception "Unable to resolve type: System.Collections.Generic.IEnumerable`1[MyApp.Services.IService]", but works just fine when only 1 service registered.
Also some general issue with generic .RegisterFor<IService,Service>() - it doesnt work at all, only .Register with type definition works, as in examples above.
This works differently in all DI containers. Some pick the first registered, some pick the last, some say "dunno,, cuz u have more than 1". I don't remember OTOH how this was solved in Umbraco, but I don't think it's supported or trustworthy via Composition. As long as something works differently in containers, it should be "unsupported" in Umbraco's abstractions to avoid compatibility issues.
I recommend either registering a custom factory method looking up concrete registrations, or registering your generic services directly with lightinject.
You can get the concrete container from:
(ServiceContainer)composition.Concrete
Unless you're building a package, in which case you should not do stuff Umbraco's DI abstraction doesn't support.
DI fails to resolve IService<T>
If one service is registered in composer as
IService<Foo>
with implementation as FooService - DI works nice, injectingIService<Foo>
as expected.But when registered more than one service as example:
IService<Foo>
,IService<Bee>
- DI cannot resolve any ofIService<T>
anymore:Produces exception at runtime "Unresolved dependency"
Similar issue is related to multiple implementations of simple service IService:
With getting dependency like this:
Produces exception "Unable to resolve type: System.Collections.Generic.IEnumerable`1[MyApp.Services.IService]", but works just fine when only 1 service registered.
Also some general issue with generic
.RegisterFor<IService,Service>()
- it doesnt work at all, only.Register
with type definition works, as in examples above.[Reposting same answer as on GitHub issue https://github.com/umbraco/Umbraco-CMS/issues/7347]
This works differently in all DI containers. Some pick the first registered, some pick the last, some say "dunno,, cuz u have more than 1". I don't remember OTOH how this was solved in Umbraco, but I don't think it's supported or trustworthy via Composition. As long as something works differently in containers, it should be "unsupported" in Umbraco's abstractions to avoid compatibility issues.
I recommend either registering a custom factory method looking up concrete registrations, or registering your generic services directly with lightinject.
You can get the concrete container from:
Unless you're building a package, in which case you should not do stuff Umbraco's DI abstraction doesn't support.
is working on a reply...