I am sure there are plenty more, but I feel I need to wrap up and move onto something different.
But not without reflecting upon what we've seen in the series and mentioning some of the frameworks that did not make it for me to review.
(Dis)-Honorable mentions
We have seen plenty, but some, unfortunately (or not) were not up for my fight with them.
That is not to say they are bad frameworks/libraries, but for some reason or another, I was not able to make my sample work with them.
Argu
This is a project that looks very interesting with its sexy DSL-like syntax...
... but I am no F# programmer (not for the lack of effort, I blame my OWB (Object-Wired Braintm) for that) and could not make it work in a C# project. So, out of the window it went.
Docopt.net
This looks interesting on paper as it has a totally different approach: instead of decorating objects or using some sort of object model to build console-specific features (help, aliases,...) it takes textual input for the parser and builds some sort of dictionary-like structure for the parsed arguments from the user.
But interesting or different does not mean I am not allowed to give up after giving it a fair try at fitting that weird syntax and model to my sample.
Not for me I suppose.
GetOpt.Net
I did not have high hopes for this one as the "documentation" was pointing to a single example in the repository, but since there is a NuGet package I gave it a shot despite the fact that the concept of command is not supported.
Unfortunately, after implementing my sample application I was only able to display the help message and was terribly upset to get a ProgrammingErrorException because I was using a single dash instead of doubling it up (fact that I found out looking at source code).
If such a simple mistake for the user results into an exception thrown at his face (or forced to be handled by the un-aided programmer) I am afraid I am not going much further with that library.
Anything worthy then?
Yeah, plenty.
Even though I believe that Powershell is the way to go I can highlight:
- the simplicity and straightforwardness of GoCommando
- the power, feature-set and polish of PowerArgs
- the object model approach of Command Line Utils but without its confusing state
- the "get it running in a breeze" approach of CLAP
Famous Last Words
I really believed that such and old problem (parsing a command line) would have fewer "let's do this again for the heck of it" but I am not complaining for the extra effort of trying.
OSS is a free country where everyone can direct their efforts the way they deem best and command line is a non-trivial-not-so-difficult problem with a low entry barrier for domain knowledge for someone that wants to start in the .NET OSS world.
Having said so, I think that we, programmers, are better off placing our efforts on something different. If not for ourselves, think of the poor souls trying to find just one framework. Let's not drown them in even more choices.
I propose a banner in Github ".NET has its share of command line parser. Newcomers beware" or maybe I can write one framework myself with everything that I like from other frameworks...
Obligatory reference to xkcd:
