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

Not possible to have multiple service impls in child container(?) #573

Closed
Amleto opened this issue May 9, 2023 · 1 comment
Closed

Not possible to have multiple service impls in child container(?) #573

Amleto opened this issue May 9, 2023 · 1 comment

Comments

@Amleto
Copy link
Contributor

Amleto commented May 9, 2023

        public class DryExamples
        {
            [Fact] // This works ok.
            public void TransferMultipleThenResolveEnumerable()
            {
                var services = new ServiceCollection();

                services.AddScoped<IPrinter, Printer>();
                services.AddScoped<IPrinter, PrinterA>();
                services.AddScoped<IPrinter, PrinterB>();
                services.AddScoped<IPrinter, NeighborPrinter>();

                var spf = new DryIocServiceProviderFactory();
                var dryContainer = spf.CreateBuilder(services);
                var msContainer = dryContainer.GetServiceProvider();

                Assert.Equal(
                    dryContainer.Resolve<IEnumerable<IPrinter>>().Count(),
                    msContainer.GetRequiredService<IEnumerable<IPrinter>>().Count());
            }

            [Fact] // I have not been able to get this to work.
            public void TransferMultipleThenResolveEnumerableFromChild()
            {
                var services = new ServiceCollection();

                services.AddScoped<IPrinter, Printer>();
                services.AddScoped<IPrinter, PrinterA>();
                services.AddScoped<IPrinter, PrinterB>();
                services.AddScoped<IPrinter, NeighborPrinter>();

                var spf = new DryIocServiceProviderFactory();
                var rootContainer = spf.CreateBuilder(new ServiceCollection());
                var childContainer = rootContainer.CreateChild(RegistrySharing.Share, "child-stamp", IfAlreadyRegistered.AppendNewImplementation);
                //childContainer.Populate(services);
                foreach (var service in services)
                {
                    childContainer.RegisterDescriptor(service, IfAlreadyRegistered.AppendNewImplementation, "child-stamp");
                }
                var msContainer = childContainer.GetServiceProvider();

                Assert.Equal(
                    childContainer.Resolve<IEnumerable<IPrinter>>().Count(),
                    msContainer.GetRequiredService<IEnumerable<IPrinter>>().Count());
            }
        }

        private interface IPrinter
        {
        }

        private class Printer : IPrinter
        {
        }

        private class PrinterA : IPrinter
        {
        }

        private class PrinterB : IPrinter
        {
        }

        private class NeighborPrinter : IPrinter
        {
        }

The first test works, and I expect to be able to do similar with a child container. However, the fact that the child service has a default key seems to break this expectation.

childContainer.Populate(services); hard-codes append-if-not-keyed, so I tried calling childContainer.RegisterDescriptor in the loop, but discovered that AppendNewImplementation and AppendNotKeyed are basically not allowed in Regsitry.WithKeyedService(...).

Functionally, I'm looking to move away from a setup with unity container that has child containers. ie child containers can resolve from parent, but cannot interfere with parent registrations. Parent cannot see child services/registrations.

Please let me know if this is achievable.

@Amleto
Copy link
Contributor Author

Amleto commented May 10, 2023

closing since this is a dupe

@Amleto Amleto closed this as completed May 10, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant