5.5.0 breaks resolution

[schuettecarsten]

I upgraded to 5.5.0 and now I get exceptions that I did not get before and that go away if I downgrade to 5.4.7. Exception is:

Unable to resolve type 'DataContext'.
Constructor Void .ctor(Microsoft.Extensions.Logging.ILogger`1[DataContext], ITenantDbContextFactory`1[CmtDbContext]) found with unresolvable parameter: ITenantDbContextFactory`1[[CmtDbContext]])dbContextFactory.

I heavily use container.Register calls and during the last changes, something broke. At the moment, I have to time to debug this as I am about to leave for the next 12 days. The only thing that I found out Stashbox knows 1176 service registrations with 5.4.7 and - without any other changes - only 1171 services with v5.5.0

[z4kn4fein]

Hi @schuettecarsten, thanks for the report! I'm going to investigate this. If you'll have some time, could you please share the registration details of the related services?

Especially for this type: ITenantDbContextFactory<CmtDbContext>

[z4kn4fein]

I've found an issue related to open generic registrations, but I'm not sure whether it's related to your issue or not. The fix is in 5.5.1, please let me know if this issue is still happening.

[schuettecarsten]

I tried 5.5.1, but the exception still occurs.

I have registered an unknown type resolution handler and logged its output. It reports that it cannot resolve ITenantDbContextFactory<CmtDbContext> immediately before the exception is thrown. In the list of registered services, I can find two service registrations for that service:

ITenantDbContextFactory<CmtDbContext> -> CmtDbContextFactory
ITenantDbContextFactory<CmtDbContext,long> -> CmtDbContextFactory

The first one should be used here, but maybe Stashbox is not able to handle this because there is a second registration with two generic parameters? But this is only an assumtion, I was not able to verify this yet.

[z4kn4fein]

Thank you for your response! Unfortunately, it's not the case, Stashbox differentiates between those two types, so it resolves CmtDbContextFactory correctly when ITenantDbContextFactory<CmtDbContext> is requested in that scenario. I assume the issue lies elsewhere.

Are you using any complex configurations on CmtDbContextFactory or DataContext?

Could you please share the peace of code that registers them?

[schuettecarsten]

It's really hard to debug and to look into the Stashbox service registrations because the ImmutableBucket implementation is not very debugger-friendly. So maybe it's a good idea to add a DebugView helper class first to be able to show all registrations in a flat list and analyze them....?

[z4kn4fein]

You can get a flat map of the registrations by calling the container.GetRegistrationMappings() method, it will give you key-value pairs of Type -> ServiceRegistration. Does this help?

[z4kn4fein]

I have added Debugger proxies for several internal structures (ImmutableTree, ImmutableBucket, etc.) in 5.5.2-preview-768, I hope this will make the debugging easier.

[schuettecarsten]

I have done some debugging and found this behaviour. I have the following service registrations for the type CmtDbContactFactory:

I use the Container.Register() method with typeFrom and typeTo set to CmtDbContextFactory and call AsServiceAlso for the four interfaces. Scope is set to singleton. This results into two service mappings:

It looks like something gets lost when using AsServiceAlso with generic interfaces. That worked in 5.4.3 (no idea why I was talking about 5.4.7 above). With the old version, the stashlbox mappings look like this:

[z4kn4fein]

Thanks for the details! I've located and fixed the issue, it'll be released soon. (Sorry for the closing, it was by accident)

[z4kn4fein]

I've released v5.5.2 with the fix, could you please verify that it works now as expected? Thanks!

[schuettecarsten]

Thank you, the issue seems to be fixed with this version. The mappings now look the same like they were with 5.4.3.

[z4kn4fein]

Thank you for the details, it did help a lot!