You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Part of the v11 internal-foundation workstream. See docs/roadmap.md and milestone #6.
Goal
Introduce Microsoft.Extensions.DependencyInjection inside the build orchestrator. Set up a composition root that registers default implementations of every infrastructure interface (file system, process runner, console host, etc.) and resolves them via constructor injection.
Consumer-facing API stays identical — Execute<T>() is still the static entrypoint; internally it builds the ServiceProvider, registers defaults, runs the orchestrator.
Scope
Add Microsoft.Extensions.DependencyInjection to Directory.Packages.props.
Create a BuildHostBuilder that produces a configured IServiceProvider per build invocation. Lives in Fallout.Build.
Plumb the IServiceProvider through BuildExecutor, ExecutionPlanner, ParameterService. Replace direct static calls with resolved dependencies.
Keep static facades (ProcessTasks.StartProcess, AbsolutePath.*) as default wrappers that resolve their dependency from a per-build ambient context (AsyncLocal<IServiceProvider> or similar). Statics on the surface, DI underneath.
Verification
BuildExecutor unit tests can now pass a fake IProcessRunner and assert it was invoked as expected. Add at least one as proof.
./build.ps1 still runs end-to-end with no behavioral changes.
No IServiceCollection.AddSingleton<T> call reaches into Fallout.Common internals — registration is shaped against the interfaces only.
Part of the v11 internal-foundation workstream. See docs/roadmap.md and milestone #6.
Goal
Introduce
Microsoft.Extensions.DependencyInjectioninside the build orchestrator. Set up a composition root that registers default implementations of every infrastructure interface (file system, process runner, console host, etc.) and resolves them via constructor injection.Consumer-facing API stays identical —
Execute<T>()is still the static entrypoint; internally it builds theServiceProvider, registers defaults, runs the orchestrator.Scope
Microsoft.Extensions.DependencyInjectiontoDirectory.Packages.props.BuildHostBuilderthat produces a configuredIServiceProviderper build invocation. Lives inFallout.Build.IFileSystem,IProcessRunner,IConsoleHost,IBuildStatePersistence.IServiceProviderthroughBuildExecutor,ExecutionPlanner,ParameterService. Replace direct static calls with resolved dependencies.ProcessTasks.StartProcess,AbsolutePath.*) as default wrappers that resolve their dependency from a per-build ambient context (AsyncLocal<IServiceProvider>or similar). Statics on the surface, DI underneath.Verification
BuildExecutorunit tests can now pass a fakeIProcessRunnerand assert it was invoked as expected. Add at least one as proof../build.ps1still runs end-to-end with no behavioral changes.IServiceCollection.AddSingleton<T>call reaches intoFallout.Commoninternals — registration is shaped against the interfaces only.Out of scope (tracked separately)
IFileSystemetc.) — [Foundation] Wrap IO/process/console statics behind injectable interfaces #91.BuildManagerwith an instance type — [Foundation] Replace BuildManager statics with instance BuildOrchestrator #90.Blocks