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.
> hefty amount of boilerplate to achieve practically nothing
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 really do disagree with you. Most of the example code that comes out of ms is just downright terrible, and encourages terrible code. They're always writing as if you're working for Reddit or Facebook scale, not the code 99.99% of their customers should be writing. I downloaded a random git project to load test a signalr app yesterday because for whatever silly compile reason I couldn't get the one inside aspnetcore to compile (which is a whole massive problem with "modern" .net in itself, how are we back to DLL hell?).
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.
Robust input validation and help, sure.
Never had a massive use for auto-complete. Maybe my console applications are just too small in scope. I write multiple programs rather than one program with "sub-operations".
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.
> This looks like a hefty amount of boilerplate to achieve practically nothing.
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.
Nobody should be writing one-off command line parsing code. If you don't want something fairly heavy like Spectre, then just pull in a lighweight library like CommandLineParser.
One trick you can use if you are super lazy is to just use a config.json file that always resides next to your exe. JSON files are very easy to edit/share, and can be trivially serialized in and out of your models for convenience (1 liner with either Newtonsoft or built-in serializer). JSON is also a good interchange format between systems, so it can quickly integrate into a bigger system without much hassle.
Yes and no, I definitely write throwaway C# console apps all the time and just go through the hassle of generating a solution and boilerplate so I might use this kind of thing.
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.
Kind of my line of thinking as well. I would never pull in a library with a 100 features when my software only needs 2 of those features. I write those 2 features myself.
a) Which of those libraries do they use only 2% of the features from? One the template is filled out, won't it be higher.
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""` ?
Neither of your examples requires anything from the program regardless of what language it's written in, let alone what arg-parsing library it uses. Quotes are evaluated by the shell; your program gets an argv.
(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.)
That is because he's giving a tiny example of a starter template for a console app.
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.
I guess they had fun doing it! Some libraries are for fun to improve command & self confidence. Usually they are beginnings of a new delightful product. So I feel it is all for good.
