MS DI AddKeyed... variant registration fails

[detoxhby]

MS DI AddKeyed... variant registration fails

[dadhi]

@detoxhby The keyed services will be supported in the DryIoc v6 version. The support is already added. The version still need the final touches.

[dadhi]

@detoxhby Here it is dotnet add package DryIoc.Microsoft.DependencyInjection --version 8.0.0-preview-01

[detoxhby]

@dadhi thanks!

Will you publish pre-release for testing beforehand? Would like to help by checking out in real projects!

[detoxhby]

@detoxhby Here it is dotnet add package DryIoc.Microsoft.DependencyInjection --version 8.0.0-preview-01

thanks, we've done testing and apart from the change in ConfigureContainer calls (IContainer to DryIocServiceProvider) the only issue is the Request class' API parameter changes of IContainer to Container which is a problem because generally we use the interface to reference the container and casting it down is unsafe
Can we ask why is this change was necessary? and if this is mandatory then what kind of workaround should we use to gain the typed container?

[dadhi]

Could you provide the example with the casting?
What are using Request.Container for?

[detoxhby]

Could you provide the example with the casting? What are using Request.Container for?

for factory based registrations/resolutions we use this for ex.:

CurrentContainer.ResolveFactory(Request.Create(CurrentContainer, ServiceInfo.Of<T>(serviceKey: key))).FactoryID

CurrentContainer is the IContainer and with v6 we need to cast it to (Container) atm

[dadhi]

@detoxhby Got it, will check.

Btw, I am still interested why do it with such a "low level" DryIoc stuff, are you integrating with some lib?

[detoxhby]

Btw, I am still interested why do it with such a "low level" DryIoc stuff, are you integrating with some lib?

we are mainly using it for factory-based scoped registrations to be able to replace them dynamically during an execution (actually, this solution was discussed with you a few years ago because it was not possible earlier :))

// registration
var factory = ReflectionFactory.Of(typeof(TImplementation), reuse, made, setup);
var id = new FactoryIdentifier<TService>(factory.FactoryID);

container.Register(typeof(TService), factory, ifAlreadyRegistered, serviceKey);
container.RegisterInstance(typeof(FactoryIdentifier<TService>), id, serviceKey: serviceKey);


// usage (context is IResolverContext)
context.CurrentScope.SetOrAdd(context.Resolve<FactoryIdentifier<T>>(), instance)

The previous ResolveFactory is used in other testing env where we need to access the main factory (due to abstraction/isolation over different DI containers) but actually not mandatory functionality, we can probably drop it if required.
If there's an alternative API to avoid this we are willing to leave low-level parts behind.