Get result of parsed command line arguments as an object

Is your feature request related to a problem? Please describe. Yes, I would like to have an “CommandLineArguments” object with immutable fields that I could pass around my application.

Describe the solution you’d like Instead of using int CommandLineApplication.Execute<ProgramSettings>(args); I’d like to have a method ProgramSettings ParseCommandLineArguments<ProgramSettings>(args); so that I could pass “Program” around.

Describe alternatives you’ve considered Currently, I’m doing the following Program.cs contains the entry point of the program and the following code:

public static int Main(string[] args) {
	if (args.Length == 1 && args[0] == "--lazy-dev-switch")
		args = LazyDevArguments();

	return CommandLineApplication.Execute<ProgramSettings>(args);
}

private static string[] LazyDevArguments(){
...
}

public static int Run(ProgramSettings settings) {
	... DoStuffWith(settings);
}

It is ugly, but at least it allows me to pass a well-formed “ProgramSettings” object around.

And in ProgramSettings.cs I have all the Options and whatnot PLUS the method OnExecute():

public int OnExecute() {
	return Program.Run(this);
}

[natemcmaster]

So, in other words, you want all the goodness of CommandLineApplication.Execute<Settings> without the requirement to implement an OnExecute method on the Settings class? If so, this is something I’ve considered adding but was basically waiting to see if anyone actually wanted it.

[natemcmaster]

Dependency injection.

Yeah, the heavy lifting is done. This is really a matter of designing an API that works well. It’s possible to implement some of this on your own with CommandLineApplication and an empty OnExecute (see example here) but this is more effort than I think should be necessary.

I’ve wanted to expose a lower level API that parsed args into a simpler dictionary-like result first. Then this result is bound to an object or the CommandArgument/Option types. I nearly wrote it into this library last year, but ended up helping the team that wrote System.CommandLine build this approach instead. I’ve been tempted to use it as the “processing engine” under the hood, but System.CommandLine doesn’t appear to be on track for a stable release anytime soon. So, I’m thinking maybe I should do it on my own instead.