-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
Add DI compatibility test #50029
Comments
I'll add a spec test. You might want to file a similar issue in https://github.com/unitycontainer/microsoft-dependency-injection/issues. cc @ENikS |
I fixed it in Unity.DI. xUnit tests are available here |
Looks good. Just out of curiosity. Is this test intended for just th unity container is is is something that should be tested i the generic test suite where the container is created using an abstract method. Since the https://github.com/unitycontainer/microsoft-dependency-injection passes all the tests i thougth it would be a good idea to add one that addresses the problem for all the IoC frameworks that want to be compatible. Perhaps I´m missing something. Just my 2 cents. |
We should add a spec test too. This scenario was implied but not tested so it should pass on all supported containers. |
Tagging subscribers to this area: @eerhardt, @maryamariyan Issue DetailsWe 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.
This works in Unity if you register the type with 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. // Andreas
|
You are resolving service from root inside your lambda, how sp should know about the scope? |
When I tested this 2,5 years ago this registration works: serviceCollection.AddTransient<ITransientService, TransientService>() How does the service provider know about the scope in that case when resolving instances? |
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.
This works in Unity if you register the type with
but not if you register it with
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.
// Andreas
UnitTestScopes.txt
The text was updated successfully, but these errors were encountered: