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.
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.
With Command Line Utils we are up for an exception.
I am going to break my self-imposed rules for code that I use. It passes the NuGet package filter but there is no project page to get from the package. That would be an automatic “thanks, but no, thanks” but I was curious enough to see what it might come from a Microsoft owned repository that I bit the proverbial bullet.
They keep coming... Let's have a look at PowerArgs.
With its NuGet package and sane, useful documentation both in the README and in the WIKI.
Next in line to be tried is Command Line Parser.
Surely comes as a NuGet package but, surprisingly, project documentation in master points to a beta version, not the stable one. Until I noticed, it caused me a couple of head scratches and a certain deal of fist waving.
The first one in this series is GoCommando.
As it needs to be in order to be considered, comes as a NuGet package and it praises itself to be small and with a mixture of interfaces and attributes.
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?
I am all in for Powershell.
I have embraced psake for my local builds.
But, somehow, someone finds a way to spoil the moment and wastes my time.
‘What is what we wanted to achieve, again?’, said the driver, taking a step back from his/here keyboard.
‘Write our beloved .NET code to perform some tasks that can be invoked from the command line.’, answered the bewildered navigator, dilated pupils in awe for the departure of the driver from The Keyboard.
‘Oh, and that hassle of parsing arguments?’, the driver asked, taking a slow approach towards the lonely desk.
‘That? I prefer not to write it, thank you very much.’, suspired a relieved navigator.
Despite having found a sensible framework for console applications (NConsoler) I was kind of put back by their drawbacks, most of them derived by the fact that attributes are used to decorate methods and arguments.
ManyConsole can be easily obtained as a Nuget package to be up and running in no time.
This framework I have used extensively and have been pretty happy with the results. I has its caveats, and that’s the reason this is not my last post of the series
NConsoler can be downloaded as a .zip file from its project page and can be obtained as a Nuget package (remember my rules for OSS libraries?).
Mono.Options comes as a Nuget package that adds source code to our solution. As the doc says is based on callbacks, that is a delegate that gets executed as soon as the command line argument is parsed.
Everything revolves around the OptionSet and a "mini DSL” that defines the arguments and their aliases, a piece of documentation and the delegate to be executed when the options is present. OptionSet helps with the parsing of the arguments and displaying the documentation.
Today I am going to write my last console application. I am done with it. My fingers refuse to type (G-d forbid) any parsing code or import any more command-line parsers and/or frameworks.