command-line-api VS ILRepack

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.

ILRepack might be what you're looking for: https://github.com/gluck/il-repack

Combine applications by merging IL, not by storing it in resources. (il-merge, il-repack and unknown to me 'libz', or write your own merger using Mono.Cecil or dnLib)

Depending on which version of .NET you're building with, there are various tools to allow you to statically link all of your assemblies into one executable. Examples are ILMerge for .NET Framework and ILRepack for .NET Core.