Kristian Hellang

And https://github.com/Azure/azure-functions-host/issues/7027, which focus on covariance. Still not entirely the same problem though.

Thanks for jumping on this @DanHarltey! 🙏🏻 > It is trying to match the provided implementation type to the service type however in the latest release this has been restricted...

Ah, yeah, that makes sense. Thanks for the explanation! I see that their `GetImplementedTypes` returns back [the hierarchy of base types](https://github.com/Azure/azure-functions-host/blob/35f7a8b9dc218071cd1b8f0ccbe396766eebfac6/src/WebJobs.Script.WebHost/DependencyInjection/DryIoc/Container.cs#L9056-L9068). I wonder if we could work around it by...

Ah, no, it won't work. It's calling `GetImplementedTypes` on the *implementation* type, not the *service* type. Nevermind 😆

> I am confident the proposed fix should not cause any issues Since this effectively makes all decorated registrations factory-based, I'm mainly concerned with performance as you can't really optimize...

If I remember correctly there's a difference in instance reuse for longer lifetimes as well. With `AsImplementedInterfaces`, if you have singleton registrations for `IA` and `IB` where both are implemented...

Right. As I look at it, this is a limitation in the MS.Ext.DI container 😞

Hi @Alan1616! 👋🏻 Sorry for the long response time! I'm not sure what your desired scenario is here. Do you want it to throw or not? 😅

> I was under the impression that .Net core had assembly scanning already. Does this just make it more user-friendly or is it something else? No, the framework itself does...

Hi @dcuccia! 👋 Thanks for filing this issue. Can you try adding `true` to a `PropertyGroup` in your project file and see if it makes a difference? 🤔