Invoking command via Parser doesn't write to console, whereas command.Invoke does

[maccsek]

I have a console application that uses System.CommandLine to parse arguments and options.

To be able to deal with exceptions better, I've switched from RootCommand.Invoke(args) to using a CommandLineBuilder in the way I saw discussed here in one of the earlier threads:

    CommandLineBuilder oCLB = new(oRootCmd);
    oCLB.UseExceptionHandler((e, c) => LogExceptionAndRaiseEvent(e));
    Parser oPrs = oCLB.Build();
    int iRC = oPrs.Invoke(p_StartupArgs);

Now I've noticed that this way of invoking doesn't write to the console anymore, neither when there is a parsing error nor when being called with the default help switch "-h".

I suspect it has to do with the second (IConsole) parameter in Invoke -- I've tried oPrs.Invoke(p_StartupArgs, new SystemConsole());, but without success. What am I missing?

[elgonzo]

If i am not mistaken, if you don't call UseDefaults on your CommandLineBuilder you would need to call UseParseErrorReporting to configure the CommandLineBuilder for parse error output.

And for the help switch "-h" not outputting anything, same reason. Due to not calling UseDefaults, you would need to call UseHelp on the CommandLineBuilder to enable the help option. (Otherwise "-h" would just generate a parse error due to it being an unknown option/token. Which you wouldn't notice unless you UseParseErrorReporting would have been called.)

So, basically, try something like this:

CommandLineBuilder oCLB = new(oRootCmd);
oCLB.UseHelp();
oCLB.UseParseErrorReporting();
oCLB.UseExceptionHandler((e, c) => LogExceptionAndRaiseEvent(e));

(See here for the things the UseDefault method does: github.com/dotnet/command-line-api/blob/3e0db9e5830f2722645b9a576f80e3650b50f23a/src/System.CommandLine/Builder/CommandLineBuilderExtensions.cs.)

However, i am hesitant to recommend using UseDefaults together with your own UseExceptionHandler call. Because UseDefaults also configures an exception handler. Therefore, calling both UseDefaults and UseExceptionHandler would result in two exception handlers being added to the CommandLineBuilder.

And there was a problem when adding multiple System.CommandLine middlewares with the same priority (such as multiple exception handlers). Due to unstable sorting algorithms being allowed for sorting of the execution order of these middlewares, it would have been exceedingly difficult (i.e. practically impossible) to reliably predict which exception handler would be called first if multiple exception handlers were defined (such as would be the case when calling both UseDefaults and UseExceptionHandler). Not sure if that sorting issue got fixed, but that is a moot point for me personally to ponder anyways (i am just a user of the library), because:

Also worth of note, it seems CommandLineBuilder will be a thing of the past, being removed from the System.CommandLine library (see here: #2107).

[maccsek]

Thank you, this was exactly what I needed! Works like a charm now, and I suppose when CommandLineBuilder gets deprecated, there'll be some other way of mixing my own exception handling with the regular help, version and parsing functionality.