External containers support via IServiceProviderFactory<TContainerBuilder>

[mauroservienti]

• Can Startup and Exit handlers be automatically handled? No
• Implementation #247
• documentation RadicalFx/documentation#113
• release (blocked by appveyor/ci#3386)
• Craft a sample RadicalFx/documentation#119

[mauroservienti]

• https://github.com/aspnet/Extensions/blob/master/src/Hosting/Hosting/src/Internal/ServiceFactoryAdapter.cs
• https://github.com/autofac/Autofac.Extensions.DependencyInjection/blob/develop/src/Autofac.Extensions.DependencyInjection/AutofacServiceProviderFactory.cs
• https://github.com/unitycontainer/microsoft-dependency-injection/blob/7c23b4724bb8d4f85d5f54adaa922415fab3b8da/src/Extensions/HostingExtension.cs

[mauroservienti]

This is way more complex than expected due to the way external containers integrate with IServiceCollection (Autofac for good reasons does a completely different thing to what Unity does for example).

It seems that the simplest approach is to leverage the general host builder as demonstrated in this blog post. The problem is that, I have a spike that attempts to use it, the Radical ApplicationBootstrapper lifecycle is completely orthogonal to the HostBuilder one making the integration very hard. The only options seem to be:

• do not provide this in 2.0.0 or in 2.1.0 as it’ll be a huge breaking change and wait for 3.0.0 that we never even talked about
• delay 2.0.0 to get this in by revamping the ApplicationBootstrapper

@nazarenomanco @micdenny thoughts?

[mauroservienti]

With #210 it is possible to create a WPF application that uses the same approach as always but with a new simpler API:

public partial class App : Application
{
    public App()
    {
        this.AddRadicalApplication(configuration => 
        {
            configuration.UseAsShell<Presentation.MainView>();
        });
    }
}

Or one that uses the generic host:

public partial class App : Application
{
    public App()
    {
        var host = new HostBuilder()
            .AddRadicalApplication(configuration =>
            {
                configuration.UseAsShell<Presentation.MainView>();
            })
            .Build();

        Startup += async (s, e) => 
        {
            await host.StartAsync();
        };

        Exit += async (s, e) =>
        {
            using (host)
            {
                await host?.StopAsync();
            }
        };
    }
}

The generic host one is more verbose, however, it allows using all the host feature among which containers pluggability:

var host = new HostBuilder()
    .UseServiceProviderFactory(new AutofacServiceProviderFactory())
    .AddRadicalApplication(configuration => 
    {
        //...
    })
    .Build();

Which makes plugging in all containers supporting Microsoft.Extensions.DependencyInjection trivially easy.

#210 still needs a lot of testing before being able to be merged.

[micdenny]

I like the generic host way

[mauroservienti]

Raised #214 and #213 to bring the new RadicalApplication model to life. Once that's in we can implement this in a new minor and in a separate package, e.g. Radical.Windows.Hosting, as I don't think it makes sense to add to Radical.Windows a dependency on the new Generic Hosting model.

[mauroservienti]

2.0.0-RC.3 with generic host support is out of the door 🎉