fix: clarify documentation for AutofacChildLifetimeScopeServiceProviderFactory

[alsami]

This PR clarifies the usage of AutofacChildLifetimeScopeServiceProviderFactory.

We might want to add some samples in the examples repo, if they don't exist. I'll create a PR hopefully soon.

fixes #90

[tillig]

The example definitely needs to be updated, but the value of the AutofacChildLifetimeScopeServiceProivderFactory, I think, is more about the ability to give it a child lifetime scope of your own creation, like if you have an existing container and you created your own root lifetime scope from that. The idea was from folks who are trying to self-host multiple app types in a single application - a shared root container, but each app type can have a separate logical root scope.

public class Program
{
  public static void Main(string[] args)
  {
    var builder = new ContainerBuilder();
    builder.RegisterType<SomethingGlobal>();
    var container = builder.Build();

    // First host has a named "root lifetime scope" of "host1".
    var host1 = Host.CreateDefaultBuilder(args)
      .UseServiceProviderFactory(new AutofacChildLifetimeScopeServiceProviderFactory(container.BeginLifetimeScope("host1")))
      .ConfigureWebHostDefaults(webHostBuilder => {
        webHostBuilder
          .UseContentRoot(Directory.GetCurrentDirectory())
          .UseStartup<Startup1>();
          })
        .Build()
        .RunAsync();

    // Second host has a named "root lifetime scope" of "host2".
    var host2 = Host.CreateDefaultBuilder(args)
      .UseServiceProviderFactory(new AutofacChildLifetimeScopeServiceProviderFactory(container.BeginLifetimeScope("host2")))
      .ConfigureWebHostDefaults(webHostBuilder => {
        webHostBuilder
          .UseContentRoot(Directory.GetCurrentDirectory())
          .UseStartup<Startup2>();
          })
        .Build()
        .RunAsync();

    // Each host listens on different ports, does different things, and shares a root
    // container but has specific registrations in their own lifetime scopes.
    Task.WaitAll(host1, host2);
  }
}

While the updated example shows creation of a container, it doesn't really show folks why that's any different or better than just creating the container directly in Startup.

[alsami]

Hey @tillig

sorry that it took me a while to update the PR been rather busy at work lately. I hope the sample is more satisfying now. I will add a proper code sample to the examples repository and raise a new PR for that.

Merry christmas!

[tillig]

I put a couple of update suggestions here to make it clear to readers that they can control the root lifetime scope - it doesn't have to be a container at all. Also a couple of notes to show how you can have a "singleton" that's only used by one of the two hosts, making a "logical root" that isn't the container.

[tillig]

I think an even more advanced use case is, like...

• Main program creates a container and registers things.
• Main program creates a child lifetime scope (tagged) and registers more per-lifetime-scope things in there.
• Main program hands that child lifetime scope to the AutofacChildLifetimeScopeServiceProviderFactory.
• The rest of the web app startup continues as normal using that factory.

This was more popular in Web API where there was, say, a Windows service that had a container and wanted to self-host an API endpoint but not sully the container with API-specific junk. Probably less popular now, but that's the idea.

[alsami]

I think I have addressed all the suggestions you have made.

The advanced use-case you have described above sounds good. I will try to build something for like that for the examples repository.

[tillig]

Sweet, thanks!