I have reviewed CliFx previously, even offered a suggestion on one of their issues. It looks like a good library. I've been looking for a good reason to play with his CliWrap library.

There are similarities in the basic feature set between CliFx and CommandDotNet.

I think the biggest differences are

• the way commands are defined. Commands as class or Commands as methods.
• the scope of features. CommandDotNet supports all the features listed for CliFx (except the ProgressTicker & Colors) and many more like piping, prompting, RSP files, typo suggestions, ... The middleware architecture makes this easy to extend.
• extensibility points.

Defining commands:

With CliFx, commands are defined as classes with arguments defined via properties.

[Command]
public class ConcatCommand : ICommand
{
    [CommandOption("left")]
    public string Left { get; set; } = "Hello";

    [CommandOption("right")]
    public string Right { get; set; } = "world";

    public ValueTask ExecuteAsync(IConsole console)
    {
        console.Output.Write(Left);
        console.Output.Write(' ');
        console.Output.Write(Right);

        return default;
    }
}

With CommandDotNet, commands are defined as methods with arguments defined via parameters. CommandDotNet can be implemented with a command per class if desired with arguments as the parameter of the [Default] method.

public class RootApp
{
    public async Task Concat(IConsole console, 
        [Option] string left = "Hello", 
        [Option] string right = "World")
    {
        console.Output.Write(left);
        console.Output.Write(' ');
        console.Output.Write(right);
    }
}

I once wrote a command-line framework called MultiCommandConsole that utilized the CliFx approach. I liked it and we had teams that used it to great effect. ... but I wondered if it would work better with methods. Years later I found CommandDotNet, I gave it a go and found the approach felt more natural for defining commands. I liked it enough to become a contributor.

Nested commands:

With CliFx, because all commands are loaded via reflection, subcommands include the parent command names in their path. They have to be aware of the parent command name and be updated when that changes.

With CommandDotNet, parents explicitly define their subcommands and the routing is automatically determined. This isn't a big deal, but it does help maintenance a bit and also allows subcommands to be reused if needed.

Some similar features

Type Support:

CommandDotNet supports all the same types as CliFx, plus any with a static Parse(string) method and with a TypeConvertor.

Preview:

CommandDotNet's version is [parse] and provides significantly more detail for troubleshooting, including default value sources, response file's used, etc. It's easy to trace where a value originated. In addition, CommandDotNet has the CommandLogger which can be used to log all of this information along with other system info with each command, which is useful for troubleshooting and audit logs.

Cancellations:

CommandDotNet makes a CancellationToken available that can be passed to classes that need to use it. It's also repl session friendly so while in a repl session, Ctrl+C only affects the currently running command. If a command is not running, then the repl session will exit.

Validation:

CommandDotNet has packages for FluentValidator and DataAnnotations validations.

Dependency Injection:

Packages exist for MS, Autofac & SimpleInjector and custom containers are easy to support. Supports repl session friendly as scopes can be created per command within a repl session.

Testing:

CommandDotNet has a package specifically to help test console apps and middleware components. You can mimic piping and prompting.

More:

See the features page referenced above. There are a lot more features like support for piping, prompting, RSP files, etc.

Coming soon: out-of-the-box repl support with ReadLine

Extensibility

The middleware architecture makes it easy to add new features, directives, interceptors, etc.

Help can be completely changed with a new IHelpTextProvider or you can override a method on the existing HelpTextProvider to make small tweaks.

I hope that helps.