Closed andrewlock closed 1 year ago
Ugh, @andrewlock I didn't realize that was part of their "spec" for how that was supposed to work. Okay. This is one of those times when I curse the conforming container behavior that's rammed down our throats
Ugh, @andrewlock I didn't realize that was part of their "spec" for how that was supposed to work. Okay.
To be totally fair, I'm not entirely sure that it definitely is, but best I understand the expectations of IServiceProviderIsService
it's "if you can resolve the type from the container, it should return true
".
This is one of those times when I curse the conforming container behavior that's rammed down our throats
😬 yeah, I totally get that. The fact there's no real spec for it doesn't help either 🙄
I was thinking that MS.DI Spec tests should catch all cases :/ Now upping to .Net 7 means more work :(
I was thinking that MS.DI Spec tests should catch all cases :/ Now upping to .Net 7 means more work :(
Just to be clear, this is "broken" in .NET 6 too, so not technically tied to the .NET 7 upgrade..
Think this will be in a new Lamar 10.0 soon.
I was just playing using Lamar with minimal APIs and I've found there are various cases where injected services aren't being inferred because Lamar's
IServiceProviderIsService
implementation isn't returntrue
for various cases:IEnumerable<T>
where multipleT
registeredIGenericService<T>
open genericConcreteClass
when not explicitly registeredSample app demonstrating the issue below. Note that in all cases, add
[FromServices]
fixes the issue - it's not the registration at issue, it's the call toIServiceProviderIsService
that's wrong. This repros on .NET 6 and .NET 7, giving the following error (indicating none of the args were resolved from DI)I haven't done an extensive search for all the cases that are/aren't found, but these seem to be the main culprits
Thanks!