Consider separating registration semantics from resolution

[tillig]

I'm working through some issues like this one and this one in Autofac trying to figure out where container.Update gets used and why.

Something I noticed is that in NancyBootstrapperWithRequestContainerBase and, subsequently, the Autofac implementation of it that the application container (an ILifetimeScope in this case) gets updated with registrations rather than having them present during initial container build in the first place. This can cause challenges with some things like AutoActivate and IStartable components. Using Update is generally also a red flag to me because it means if something has already been resolved out of the container (unlikely, but possible) then it could be inconsistent with the same service type that gets resolved post Update.

Have you considered separating resolution of bootstrapper components (the Get methods on the bootstrapper class) from the registration of components (the Register tasks)?

I do recognize you may be pretty far down the path to make such a change, but I figured I'd ask.

[khellang]

The short answer is; yes 😉

We realize that this is suboptimal, but there's not much we can do about it using the existing design. We've prototyped a new version of the Nancy bootstrapper that allows this. You can check it out here

[tillig]

Oh, yup, that looks way better. Cool beans, that prototype looks nice. Thanks for the pointer!