Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DI compatibility #91

Open
ENikS opened this issue May 13, 2021 · 0 comments
Open

DI compatibility #91

ENikS opened this issue May 13, 2021 · 0 comments
Assignees
Labels
Bug 🐛 Requires Investigation 👮 Requires further verification

Comments

@ENikS
Copy link
Contributor

ENikS commented May 13, 2021

We are currently using Unity in some of our projects and want to use it with asp.net core. To enable this feature we use the "Unity.Microsoft.DependencyInjection - 2.1.1". We also register some types in the default ServiceCollection provided here that then resolves types from the Unity registrations. There seems to be an issue how unity resolves object by using lambda functions. Since all the DI tests runs successfully using the Unity bridge perhaps the "Microsoft.Extensions.DependencyInjection.Specification.Tests" needs to address this.

The issue is related to scoped containers.

Create and register a transient type that takes a scoped type as parameter.
Create service provider
Create scoped provider
Make sure that the scoped type comes from the child container when getting the transient type.
This works in Unity if you register the type with

serviceCollection.AddTransient<ITransientService, TransientService>()
but not if you register it with

serviceCollection.AddTransient<ITransientService>(sp=>new TransientService(sp.GetRequiredService<IScopedService>()))
The lamda function receives the root container when resolving types in the scoped container.

Attaching test case. Not XUnit :(

I can rewrite the test in XUnit and perhaps reuse some of the existing test structures if this is an issue that you feel should be addressed.

See dotnet/runtime#50029

@ENikS ENikS added the Requires Investigation 👮 Requires further verification label May 13, 2021
@ENikS ENikS self-assigned this May 13, 2021
@ENikS ENikS added the Bug 🐛 label May 13, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug 🐛 Requires Investigation 👮 Requires further verification
Projects
None yet
Development

No branches or pull requests

1 participant