8.2.0+ Breaks Code While 8.1.0 Does Not: `This service descriptor is keyed. Your service provider may not support keyed services.`

[Mike-E-angelo]

Description

There appears to be an issue with using 8.2.0+ of this library as discussed here:
JasperFx/lamar#395

Reverting back to 8.1.0 does indeed fix the issue.

Reporting here to track and to hopefully resolve with fix.

Reproduction Steps

1. Run this test.
2. Note the thrown exception:
3. Revert back to 8.1.0
4. Note successful passing test with no exception thrown

Expected behavior

No Exception thrown.

Actual behavior

Exception thrown:

System.InvalidOperationException
This service descriptor is keyed. Your service provider may not support keyed services.
   at Microsoft.Extensions.DependencyInjection.ServiceDescriptor.ThrowKeyedDescriptor()
   at Microsoft.Extensions.DependencyInjection.ServiceDescriptor.get_ImplementationFactory()
   at LightInject.Microsoft.DependencyInjection.DependencyInjectionContainerExtensions.CreateServiceRegistration(ServiceDescriptor serviceDescriptor, Scope rootScope)
   at LightInject.Microsoft.DependencyInjection.DependencyInjectionContainerExtensions.<>c__DisplayClass1_0.<RegisterServices>b__0(ServiceDescriptor d)
   at System.Linq.Enumerable.SelectIListIterator`2.Fill(IList`1 source, Span`1 results, Func`2 func)
   at System.Linq.Enumerable.SelectIListIterator`2.ToList()
   at LightInject.Microsoft.DependencyInjection.DependencyInjectionContainerExtensions.RegisterServices(IServiceContainer container, Scope rootScope, IServiceCollection serviceCollection)
   at LightInject.Microsoft.DependencyInjection.DependencyInjectionContainerExtensions.CreateServiceProvider(IServiceContainer container, IServiceCollection serviceCollection)
   at LightInject.Microsoft.DependencyInjection.LightInjectServiceProviderFactory.CreateServiceProvider(IServiceContainer containerBuilder)
   at DragonSpark.Composition.Construction.Factory.CreateServiceProvider(IServiceContainer containerBuilder) in D:\Quikzer\Framework\DragonSpark.Composition\Construction\Factory.cs:line 17
   at Microsoft.Extensions.Hosting.HostApplicationBuilder.Build()
   at Microsoft.AspNetCore.Builder.WebApplicationBuilder.Build()
   at DragonSpark.Application.Hosting.Server.Run.WebApplicationHostBuilder.Build() in D:\Quikzer\Framework\DragonSpark.Application.Hosting.Server\Run\WebApplicationHostBuilder.cs:line 34
   at DragonSpark.Application.Compose.InitializedAwareHostBuilder.Build() in D:\Quikzer\Framework\DragonSpark.Application\Compose\InitializedAwareHostBuilder.cs:line 29
   at DragonSpark.Application.Run.RunApplication.Get(String[] parameter) in D:\Quikzer\Framework\DragonSpark.Application\Run\RunApplication.cs:line 22
   at DragonSpark.Application.Testing.Run.ConfigureNewTests.Verify() in D:\Quikzer\Framework\DragonSpark.Application.Testing\Run\ConfigureNewTests.cs:line 23
   at System.RuntimeMethodHandle.InvokeMethod(Object target, Void** arguments, Signature sig, Boolean isConstructor)
   at System.Reflection.MethodBaseInvoker.InvokeWithNoArgs(Object obj, BindingFlags invokeAttr)

Regression?

8.1.0

Known Workarounds

Pin to 8.1.0

Configuration

.NET8

Other information

Thank you very much for all your efforts out there 🙏

[RussKie]

dotnet/extensions don't exactly follow the .NET release cycle, nor follow the semver convention. This repo is on a monthly release cadence and each "point" release can bring new API and a possibility of breaking changes (though it's something we, generally, avoid as much as we can).

With this, if you upgrade to 8.2+ you may need to upgrade your code.

[Mike-E-angelo]

Thank you for your reply @RussKie it is appreciated. Are you able to point me in the direction of this breaking change so that I can further understand what is occurring?

[RussKie]

Here are the release notes: https://github.com/dotnet/extensions/releases/tag/v8.2.0. I don't see anything obvious.
Also, looking at your stack trace - I don't see any dotnet/extensions libraries in it, it's all .NET runtime and ASP.NET Core libraries. The error message is reasonably clear as well - you're trying to use keyed services alongside non-keyed services.

Your issue looks related to dotnet/runtime#95789, which appears to have been fixed in dotnet/runtime#105776 for .NET 9. It may gets backported to .NET 8, if stars align.

[Mike-E-angelo]

Indeed @RussKie there is not a mention of your library at all. I am glad we share the same concern there. 😀 It is only by happenstance (Google magic) that I happened to find the aforementioned issue that recommended backpin to 8.1.0. Regardless of the reason, this makes it look like your library is at fault.

For some further context here, I am attempting to adopt Aspire and everything worked well except this one hitch. I am pretty certain I will not be the last one who encounters this, so it's beneficial to help others reduce the grief experienced while onboarding to the new tech. As I am sure you will understand, we want things to "just work" without rummaging through the weeds to figure out why this problem goes away due to pinning a previous version of a library that makes it all go away.

I greatly appreciate you taking the time to dig up the resources. I will take a peek and update here with my findings. 👍

[Mike-E-angelo]

Update: looks like a PR is on the way for 8.0:
dotnet/runtime#106841

🤞

[RussKie]

Could provide a simple/distilled repro so that we could investigate?

[Mike-E-angelo]

Hi @RussKie I did provide a repository and failing test in the set of my instructions within the original report. Please let me know if you are looking for something else and I will assist you.

[RussKie]

The link points to a large repository, which means we'll have to debug extra code. This is why we need a small and distilled repro.

[Mike-E-angelo]

Ah, indeed. The repo is large but the referenced test is one line of code that demonstrates the problem. I was capturing the issue as found in the field as a starting point. 👍

However, let's first take a step back here to revisit understandings and assumptions before doing any additional work.

This is a confirmed issue that has been fixed in .NET9 and as I mentioned has a fix on the way to .NET8. As we discussed, this issue is not directly due to your library but (as I understand it) has to do with a dependency on the runtime that causes this issue. It just happens to be yours that references the library that is causing the grief.

So, as I understand it, this issue is resolved with a PR on the way to a future version of .NET8. We can use 8.1.0 pinned until then.

Is there another aspect to this that I do not understand?