Update Splat.Autofac to work with Autofac 5.0

[ronaldvdv]

Describe the bug
Starting with Autofac 5.0, containers are mutable. See corresponding pull request and release notes . This gives startup errors when using Splat.Autofac.

Steps To Reproduce
Provide the steps to reproduce the behavior:

• Install Splat.Autofac 9.3 and Autofac 5.0.0 packages
• In your startup code, call the IContainer.UseAutofacDependencyResolver() extension method.
• When running your application, this gives an exception: Method not found: 'Void Autofac.ContainerBuilder.Update(Autofac.Core.IComponentRegistry)'.

Environment(please complete the following information):

• OS: Windows 10
• Version: Autofac 5.0.0, Splat.Autofac 9.3

[glennawatson]

Thanks for the report

This is related to #463

[RLittlesII]

Changing this to a feature request. Autofac has breaking changes in their v5.0 API. We don't support that API yet.

[ronaldvdv]

Thanks, you're right! :-) And I would be interested in picking this up, too. Just from a design perspective I'm wondering - what is the main reason Splat was designed with mutable dependency containers in mind? What are the main things that would break or even become impossible (within Splat itself) without that? I can imagine if the problems within Splat are limited but many other projects depend on it, we could make a separate package Splat.Autofac5?

Edit: in my scenario, ReactiveUi is the main reason for using Splat. So I can imagine there's no simple solution without also considering changes to ReactiveUI and its initialization process...

[RLittlesII]

My thought is it would be something we target for the next major release. If we need to provide early access to the package itself we can use GitHub Packages to release a version if you are in a pressing need to migrate to Autofac 5.x

Autofac provided examples of how it could be done. We just need to evaluate how to make those options work within the Splat Adapter.

As for Splat. It is a service locator, it is a dependent library for ReactiveUI. It was designed to be extremely lightweight and fast. There is already discussions around how we are going to overhaul the initialization, splat will still be at the root of that.

[ronaldvdv]

Indeed I looked at some of the open discussions in the ReactiveUI repository - it seems there are multiple :-D Not sure how to contribute best, but I guess the more difficult questions to be answered first are on ReactiveUI side. If we want ReactiveUI to cooperate nicely with DI frameworks that separate the service registration phase from the service resolving phase, the initialization "magic" in ReactiveUI needs a bit of redesigning: issue and rfc and follow these same two steps.

Perhaps a quick fix could be, that we have a mutable dependency resolver adapter for Autofac. It gets an original IContainer as a constructor argument. Whenever it is asked to make changes, it creates a new lifetime scope (see Autofac documentation) and then stores the updated container. Requests to the dependency resolver for resolving services are always forwarded to the most recent container.

This would not work perfectly if applications also create their own lifetime scopes - those scopes would never see the changes made using the mutable dependency resolver...

[skaman]

Any news about this?

[skaman]

At the moment I ended up to this workaround. It's far to be elegant but, until Splat will not correctly support it, this work for my needs.

In my case I'd like to use ReactiveUI with Blazor server and Autofac 5. The AutofacDependencyResolver will register every type to 2 differents ContainerBuilder. One is internal and is used to satisfy Splat (calling multiple times the BeginLifetimeScope to workaround the immutability), and the other one is the real ContainerBuilder of my application.

Here the custom AutofacDependencyResolver: https://gist.github.com/skaman/39506a11657dbaae69101eeeb3e4a5e0

Inside the startup, I used it in this way

public void ConfigureContainer(ContainerBuilder builder)
{
    var resolver = new AutofacDependencyResolver(builder);
    Locator.SetLocator(resolver);

    Locator.CurrentMutable.InitializeReactiveUI();

    builder.RegisterInstance(resolver);

    builder.RegisterType<MyType1>();
    builder.RegisterType<MyType2>();
    // and so on ...
}

public void Configure(IApplicationBuilder app, IWebHostEnvironment env, QldbService qldbService)
{
    var lifetimeScope = app.ApplicationServices.GetAutofacRoot();
    var resolver = lifetimeScope.Resolve<AutofacDependencyResolver>();
    resolver.SetLifetimeScope(lifetimeScope);

    // continue with normal configure flow ...
}

Gist

AutofacDependencyResolver for AutoFac5 (temporary workaround until is correctly supported by Splat)

AutofacDependencyResolver for AutoFac5 (temporary workaround until is correctly supported by Splat) - AutofacDependencyResolver.cs

[glennawatson]

Thanks Until autofac allows some sort of mutability this might be the only way.

…

On Sun, 16 Aug 2020, 10:52 pm Sandro Cavazzoni, ***@***.***> wrote: At the moment I ended up to this workaround. It's far to be elegant but, until Splat will not correctly support it, this work for my needs. In my case I'd like to use ReactiveUI with Blazor server and Autofac 5. The AutofacDependencyResolver will register every type to 2 differents ContainerBuilder. One is internal and is used to satisfy Splat (calling multiple times the BeginLifetimeScope to workaround the immutability), and the other one is the real ContainerBuilder of my application. Here the custom AutofacDependencyResolver: https://gist.github.com/skaman/39506a11657dbaae69101eeeb3e4a5e0 Inside the startup, I used it in this way public void ConfigureContainer(ContainerBuilder builder) { var resolver = new AutofacDependencyResolver(builder); Locator.SetLocator(resolver); Locator.CurrentMutable.InitializeReactiveUI(); builder.RegisterInstance(resolver); builder.RegisterType<MyType1>(); builder.RegisterType<MyType2>(); // and so on ... } public void Configure(IApplicationBuilder app, IWebHostEnvironment env, QldbService qldbService) { var lifetimeScope = app.ApplicationServices.GetAutofacRoot(); var resolver = lifetimeScope.Resolve<AutofacDependencyResolver>(); resolver.SetLifetimeScope(lifetimeScope); // continue with normal configure flow ... } <https://camo.githubusercontent.com/0aeb324a3445c618a67c0140da8216d28af304fa/68747470733a2f2f6769746875622e6769746875626173736574732e636f6d2f696d616765732f6d6f64756c65732f67697374732f676973742d6f672d696d6167652e706e67> <https://camo.githubusercontent.com/040b5519c6d1891329f5f6d3e511003657131cf2/68747470733a2f2f6769746875622e6769746875626173736574732e636f6d2f66617669636f6e732f66617669636f6e2e737667> Gist *AutofacDependencyResolver for AutoFac5 (temporary workaround until is correctly supported by Splat) <https://gist.github.com/skaman/39506a11657dbaae69101eeeb3e4a5e0>* AutofacDependencyResolver for AutoFac5 (temporary workaround until is correctly supported by Splat) - AutofacDependencyResolver.cs — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#465 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABMQMMJ2ZJX2L7B6KWSAVHLSA7I7HANCNFSM4KPFERRQ> .

[HrlecMatej]

I doubt that's likely to change, since the Autofac's Update method was removed so that containers can be generally immutable.

[glennawatson]

We're unlikely to support autofac going into the future due to it.

[skaman]

I doubt that's likely to change, since the Autofac's Update method was removed so that containers can be generally immutable.

I agree, immutability is a feature in autofac 5.x: https://autofaccn.readthedocs.io/en/latest/best-practices/#consider-a-container-as-immutable

Best Practices and Recommendations — Autofac 5.2.0 documentation

[glennawatson]

Closing this issue since we are just not going to support autofac 5

[skaman]

May I ask, if you know, some suggestion about an alternative IoC container that is compatible with Splat and full featured like autofac? The main feature that i need in my project is the child scopes

[glennawatson]

I'll research and get back to you on that one

[HrlecMatej]

Autofac is the most popular .NET DI (at least by Github Stars), so I would probably not be the only one, who would prefer for a solution to be found.
skaman's workaround could perhaps be built upon, since child lifetime scopes are the only way Autofac supports any dynamic registrations.

[glennawatson]

Hey there. locking this thread from further conversation.

[glennawatson]

We will welcome pr for this issue but this is not a priority of the team at the moment.

[glennawatson]

Unlocked in case anyone wants to work out contact details to discuss offline for providing their own PR to splat.

[HrlecMatej]

This is my attempt at a PR. Thank you to "skaman" for coming up with the workaround.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.