Given the antecedents and how many times this has been done, who would have thought there was still even more libraries to parse the command line and dispatch commands?

Again?

This tweet

A .NET command line parser: What's the best choice?

— James Newton-King ♔ (@JamesNK) September 20, 2016

opened the door to, yet again, do the same thing again in a mind boggling number of slightly different ways. What’s not to like?

A bit of history

I will be taking the same base example I did some years ago:

Which, basically, boils down to:

• two commands: something and something-else dispatched from whichever command line argument is provided
• each command has arguments with different types: string, numbers, booleans and lists; provided from the command line
• arguments can be mandatory or optional
• each command takes a dependency (not coming from the command line, though) so we can test whether they play nice with some sort of dependency injection.
• command line documentation is important, really

The point being?

Yeah, I know I said that one should not use custom libraries, but do use Powershell to call your raw .NET code.
But I am also aware that there are quite a few people that are (yet, hopefully) not comfortable enough with Powershell (shame on them, really) and that, sometimes, is easier to stick a NuGet package and get going from there.

It is also fun to identify how a “simple” and solved task can be approached from several different angles. And it is also healthy to read a bit of someone else’s code and get a feeling on how other OSS projects lie in terms of documentation and community.

 

Not Last Console Series

1. The Beginning (this)
2. GoCommando
3. Command Line Parser
4. PowerArgs
5. LBi.Cli.Arguments
6. Command Line Utils
7. CLAP
8. Wrap-up