command-line-api VS CommandLineUtils

System.CommandLine is a very good parser but you need a lot of boilerplate code to get going and the API is hard to discover.

using System.CommandLine.Invocation; using Microsoft.Extensions.DependencyInjection; using Microsoft.Extensions.DependencyInjection.Extensions; namespace System.CommandLine.Builder; internal static class DependencyInjectionMiddleware { public static CommandLineBuilder UseDependencyInjection(this CommandLineBuilder builder, Action configureServices) { return UseDependencyInjection(builder, (_, services) => configureServices(services)); } // This overload allows you to conditionally register services based on the command line invocation context // in order to improve startup time when you have a lot of services to register. public static CommandLineBuilder UseDependencyInjection(this CommandLineBuilder builder, Action configureServices) { return builder.AddMiddleware(async (context, next) => { // Register our services in the modern Microsoft dependency injection container var services = new ServiceCollection(); configureServices(context, services); var uniqueServiceTypes = new HashSet(services.Select(x => x.ServiceType)); services.TryAddSingleton(context.Console); await using var serviceProvider = services.BuildServiceProvider(); // System.CommandLine's service provider is a "fake" implementation that relies on a dictionary of factories, // but we can still make sure here that "true" dependency-injected services are available from "context.BindingContext". // https://github.com/dotnet/command-line-api/blob/2.0.0-beta4.22272.1/src/System.CommandLine/Invocation/ServiceProvider.cs context.BindingContext.AddService(_ => serviceProvider); foreach (var serviceType in uniqueServiceTypes) { context.BindingContext.AddService(serviceType, _ => serviceProvider.GetRequiredService(serviceType)); // Enable support for "context.BindingContext.GetServices<>()" as in the modern dependency injection var enumerableServiceType = typeof(IEnumerable<>).MakeGenericType(serviceType); context.BindingContext.AddService(enumerableServiceType, _ => serviceProvider.GetServices(serviceType)); } await next(context); }); } }

command-line-api

I wouldn't go so far as to call it a dead duck. The project is being actively worked on. https://github.com/dotnet/command-line-api

This looks really nice.

I've been spending a lot of time with python lately because of new project work, I had never really used python before. It's been really cool to keep finding stuff like this.

The equivalent of something like in the .net world (eg https://github.com/dotnet/command-line-api) and even powershell modules (https://learn.microsoft.com/en-us/powershell/module/microsof...) have a steeper learning curve and take significantly MORE work to set up for the end-user.

https://github.com/dotnet/command-line-api is a library that facilitates making commandline executables with nice arguments and options. It's a little complicated but if you're going to pack in a lot of functionality, you need something like this.

if you're looking into command line utilities built in c#, you might want to check out System.CommandLine. You'll be able to build your comands in c#.

What you're trying to do can be accomplished with something like System.CommandLine.DragonFruit. This basically lets you define a strongly typed Main method overload, and it handles converting the string[] for you

System.Commandline is my current favorite.

The library doesn't support that format, here you can see that MultipleValues means for example "-o value1 -o value2" Options Support options with multiple values · Issue #311 · natemcmaster/CommandLineUtils · GitHub

You could roll your own with some command-line argument processing. You could write that yourself and use reflection, or for an example from a library I've used, example.

I want to test how my tools generated files and folders in the destination with different arguments passed to the program. However, in my old code, I put all the logic of working with arguments in the static int main( string[] args) function. I could not use Interface and Dependency injection to mock the CLI tools because CommandLineUtils does not have an interface library. Luckily, I found this guidance from the owner of CommandLineUtils, and he advised that "Split the command-line argument parser and application execution into separate class structures" to test various options programmatically. It is a great suggestion, and I rewrote my program by adding class CommandLineOptions and adding logic to class Generator to make it works with CommandLineOptions. I can kill two birds with one stone by this change: code refactoring and writing better tests. Another problem I had was my folder structure. Before, I put the project's sln file, .git file , and src files in the root of the folder. However, when I added a new test project for Shinny-SSG, I had it outside my git folder, and it would be impossible to commit the change and put it in my remote repository. To resolve this, I had to change my folder structure to this:

Thanks to https://github.com/natemcmaster/CommandLineUtils for supplying a lot of the command structures. If you're interested in creating your own dotnet tool, this is highly recommended.