Nested scope doesn't see new registrations in parent scope

[ilya-g]

Changes to the parent component registry don't propagate well to the nested registry when the service in the nested registry is already initialized.

Steps to reproduce

1. Create parent and nested scopes. Make nested scope to create it's own registry.

       var container = new ContainerBuilder().Build();
       var nested = container.BeginLifetimeScope(_ => { });

2. Make nested scope to initialize service registration info for some service:

           nested.Resolve<IEnumerable<string>>(); 

3. Update parent scope and try to resolve updated service implementation from nested scope

           var builder = new ContainerBuilder();
           builder.RegisterInstance("s1");
           builder.Update(container);
   
           Assert.That(nested.Resolve<string>(), Is.EqualTo("s1"), "Nested scope should get update from the parent scope");

Expected output
Updated implementation gets resolved from nested scope.

Aсtual output
Autofac.Core.Registration.ComponentNotRegisteredException : The requested service 'System.String' has not been registered.

[tillig]

By and large, scopes, once created are immutable. The Update method is kind of a hack to get things into a single scope, but generally it's truly just a hack. When you create a child scope, the parent's registry gets copied over into the child. Updating the parent doesn't update the copy with the child.

I'll mark this as an enhancement. There are some other internal things we want to fix and this would go along with those, possibly even being fixed as a byproduct of fixing the other issues.

[alexmg]

This isn't something that I have ever run into before. Do you have an example of a situation where this has been required?

[tillig]

I think we're going to close this as "won't fix." Scopes, generally speaking, are immutable once you create them and updating a container out from under a scope will actually cause more problems than it solves - for example, you may have already resolved something from the child scope that is incorrect now based on changes made in the parent scope after the resolution takes place.

Instead, I'd recommend looking at ways to get around actually modifying the parent scope and hoping the child scope sees new parent registrations post-creation. In general, I'd say best practice is to really try to treat containers as immutable.

[tillig]

It appears [Nancy bootstrapping] uses Update as a way to add registrations to the container post-facto.

I guess I'll open this back up to see if we need to do something here, though I still feel this is a "won't fix." I'd just as soon remove the "Update" method to avoid the challenges/inconsistencies it causes in various behaviors like AutoActivate and IStartable.

[tillig]

Re-closing as won't fix. Nancy has an issue to handle removal of their use of Update and when we treat a container as immutable this won't be an issue.