Extensions: Add DI compatibility test

[aarrgard]

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.

1. Create and register a transient type that takes a scoped type as parameter.
2. Create service provider
3. Create scoped provider
4. 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()
but not if you register it with
serviceCollection.AddTransient(sp=>new TransientService(sp.GetRequiredService()))

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

[pakrym]

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

[ENikS]

@aarrgard @pakrym I will take a look

[ENikS]

I fixed it in Unity.DI. xUnit tests are available here

[aarrgard]

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.

[pakrym]

We should add a spec test too. This scenario was implied but not tested so it should pass on all supported containers.