Autofac `IStartable.Start()` invoked before `RegisterBuildCallback` - autofac

Question

The IStartable.Start() method of a component is invoked before RegisterBuildCallback.
Is it a bug or a feature?
According to the docs:
Startable Components: A startable component is one that is activated by the container when the container is initially built
and
Container Build Callbacks: You can register any arbitrary action to happen at container build time by registering a build callback. A build callback is an Action and will get the built container prior to that container being returned from ContainerBuilder.Build.
So, the order of operation doesn't seem to be defined, but in my opinion container build callback are part of the "container build process", where starting components should happen only when everything else is built already.
Repro:
using System;
using Autofac;
namespace AutofacBuildOrderRepro
{
class Program
{
static void Main(string[] args)
{
var builder = new ContainerBuilder();
builder.RegisterBuildCallback(ctx => StaticClass.ObjectProvider = () => new object());
//this fails:
builder.RegisterType<StartableClass>().As<IStartable>().AsSelf().SingleInstance();
builder.Build();
//this works:
//builder.RegisterType<StartableClass>().AsSelf().SingleInstance();
//var container = builder.Build();
//container.Resolve<StartableClass>().Start();
}
class StartableClass : IStartable
{
public void Start()
{
StaticClass.Run();
}
}
public static class StaticClass
{
public static Func<object> ObjectProvider { private get; set; }
public static void Run()
{
if (ObjectProvider== null)
{
throw new InvalidOperationException("ObjectProvider is null");
}
Console.WriteLine("Success");
}
}
}
}
Exception call stack:
Unhandled Exception: Autofac.Core.DependencyResolutionException: An exception was thrown while executing a resolve operation. See the InnerException for details. ---> ObjectProvider is null (See inner exception for details.) ---> System.InvalidOperationException: ObjectProvider is null
at AutofacBuildOrderRepro.Program.StaticClass.Run() in c:\path\AutofacBuildOrderRepro\Program.cs:line 39
at AutofacBuildOrderRepro.Program.StartableClass.Start() in c:\path\AutofacBuildOrderRepro\Program.cs:line 27
at Autofac.Core.Resolving.InstanceLookup.StartStartableComponent(Object instance)
at Autofac.Core.Resolving.InstanceLookup.Execute()
at Autofac.Core.Resolving.ResolveOperation.GetOrCreateInstance(ISharingLifetimeScope currentOperationScope, IComponentRegistration registration, IEnumerable`1 parameters)
at Autofac.Core.Resolving.ResolveOperation.Execute(IComponentRegistration registration, IEnumerable`1 parameters)
--- End of inner exception stack trace ---
at Autofac.Core.Resolving.ResolveOperation.Execute(IComponentRegistration registration, IEnumerable`1 parameters)
at Autofac.Core.Lifetime.LifetimeScope.ResolveComponent(IComponentRegistration registration, IEnumerable`1 parameters)
at Autofac.Core.Container.ResolveComponent(IComponentRegistration registration, IEnumerable`1 parameters)
at Autofac.Builder.StartableManager.StartStartableComponents(IComponentContext componentContext)
at Autofac.ContainerBuilder.Build(ContainerBuildOptions options)
at AutofacBuildOrderRepro.Program.Main(String[] args) in c:\path\AutofacBuildOrderRepro\Program.cs:line 15
I tried it with Autofac ver. 4.8.1 and 3.0.4.

Answer 1

The short version: Use IStartable.Start(), AutoActivate, and build callbacks sparingly. If you need to control order, instead of using a combination of callbacks and startables, execute the operations you need in the appropriate order in your application code after building the container. Use a build callback to run your specifically ordered logic rather than trying to ensure a particular order across all three of these things.
The long version: In general the current logic is to run IStartable, then AutoActivate, then build callbacks.
That is the logic today, it is not guaranteed that will be the logic tomorrow.
The reason this isn't necessarily guaranteed:
If one IStartable depends on another IStartable, they get run in dependency order (the dependency gets started before the thing consuming the dependency).
If an IStartable or AutoActivate tries to create a child lifetime scope during Start or activation and starts resolving things, that will throw off the order. (Yes, this was a recent issue we had filed. People do this.)
The notion of IStartable and AutoActivate somewhat fit with the notion of build callbacks, so the logic for these and/or other startup "on container build" logic may be refactored/moved to become build callbacks, which may affect ordering.
Personally, I don't use any of these things. They are convenient mechanisms for bolting application startup logic together with the container creation process but it somewhat breaks single responsibility principle by co-opting a dependency setup mechanism with unrelated logic. That may not be what's happening here, but it happens a lot "in the wild." Gotchas like "I need to control the order things run in except there is also a dependency order things need to run in" really get people into sticky situations.
Anyway, if it's not working or it's running in an order you're not expecting, consider things like OnActivating in conjunction with SingleInstance so it happens more lazily; or move some of that initialization logic out of container build and into specific logic for your app where you can control that order manually.