As a .Net developer I've.. never seen people write code at work like this. This looks like a hefty amount of boilerplate to achieve practically nothing. I'm guessing this guy learned Asp.Net first.
It depends on what you mean by "practically nothing". If you're going to deliver a non-trivial commandline application to do something useful for other people, it needs to have robust input validation, proper auto-complete and help that's sensitive to what command subcommand/option you're trying to invoke. Would also be nice to also get an --update option more or less "out of the box"(+).
Those things add up!
(+) With .net 5, I now see that clickonce allows you to publish a console app from visual studio, but it doesn't seem to work the way one one would expect. The console app is launched from a start-menu application ref, just like a wpf app. I would have liked it to add the command to the user's path so they could just use once they installed it.
I've always used the (rather dated) library NDesk.Options [0]. Even though it was written way back in the .net 2 days. For me, it seems to hit a very nice sweet spot between power and complexity.
I think now folks have gotten used to auto-complete in powershell commands. It's really harsh to not give that to them when they're expecting it. :-)
It was hundreds of lines long, didn't work properly, and once I'd culled the crap, pointless, boilerplate was a whole 20 lines.
C# really is great, you can write a lot with some really clear, obvious, terse code. But the awful, over-engineered, useless code that seemingly 75% of C# developers write is not, it's unreadable crap that adds nothing to performance, massively hinders readability and tarnishes the language.
I have yet to find a good way to avoid boilerplate in handling command line input on my console applications.
My naïve self feels that it should be standard, and yet every console application operates with different nuances. It's also a part of code that I see a disproportionate amount of bugs/feedback on (for sufficiently complicated programs). I see developers consistently underestimate the work required on handling command-line input.
I don't think this guys solution is a silver bullet but I'm happy to see the methods.
It's a bit heavy, I'd have to invest some time learning his framework but could be worth it. I've certainly written lots of command line parsing and logging code I'm not proud of.
b) There are certain things that look simple, but you _do not_ want to waste your time coding the corner cases yourself when this is a solved problem.
e.g. You might think that commandline args is simple, but it is very much not. if you '-file foo.txt' working, how will you handle '-file "C:\Program Files (x86)\bar\foo bar.txt" ' ?
If you get `-message hello` ? working, will your code handle `-message "hello, "friend""` ?
Having this prebuilt is useful.
(Yes, Windows is complicated by having two different built-in parsers for argv [CRT and shellapi] because the kernel itself doesn't have a concept of argv. But if we're talking about .Net programs then the runtime makes that choice and gives your entrypoint an argv, so again quote-evaluation is not in the program's purview.)
I'm less familiar with the library that OP is using, but it seems to be here: https://github.com/spectresystems/spectre.console/blob/main/...
Going in the other direction, generating command lines: https://github.com/natemcmaster/CommandLineUtils/blob/main/s...
I don't recommend re-inventing this
If you were writing a "production-level" console app with multiple commands, logging, needed DI, input validation, nice looking progress bars, etc. Then this is pretty much what I'd want for a console template tbh.
Spectre.Console looks insanely nice.