Proposal: UseSystemCommandLine extension for IHostBuilder

[pschmerling]

Hi team,

while building .NET apps (console, WPF, Windows-Service) on top of System.CommandLine, I often combine it with Microsoft.Extensions.Hosting. Today each app must: • parse args manually, • inject ParseResult into DI, • handle --help / validation, • wire optional post-parse configuration.

I propose a small host extension:

Host.CreateDefaultBuilder(args)
    .UseSystemCommandLine(rootCommand, args, (parseResult, services) =>
    {
        // optional post-parse configuration
    });

Benefits: • Unified startup for console, WPF and service apps • Single parse before building the host • DI-friendly access to ParseResult or a typed accessor

This would live as an additive helper, so no breaking change.

Would you consider such an addition? I’m happy to draft a PR if the idea fits the roadmap.

Thanks!

[dodexahedron]

+1

This would simplify my migration to SCL from PowerArgs, for an application based on the hosting APIs that can operate as a service, a one-shot CLI invocation, and an interactive invocation with a TUI depending on the command line.

With the current API, I deal with it by making the startup phase of the application its own isolated step which makes use of SCL, applying any relevant options to the IConfiguration already bound to a strongly-typed settings type. That is then injected into the host builder.

Having first-class support for it in the host builder would consolidate more of the logic for configuration, which is currently living in the part that runs SCL, rather than its normal place in the host builder pipeline.

That already provides unified startup for all modes of startup, but it's just somewhat more disjoint in the code than it could otherwise be.

Another big advantage of having it integrated into the host builder is logging. Right now, that startup phase that runs SCL before the host builder setup phase has a brief time during which the user's logging configuration can't yet be respected because it has to wait for SCL to finish doing its work before the configuration is actually loaded. To avoid a second configuration pass, environment variables are pretty much the only viable option right now, and that's very non-ideal to me. That underscores your second bullet point. 👍