My preferred .NET console stack
devlead.se
My preferred .NET console stack
1–10 of 119 posts
Re: My preferred .NET console stack
#2For console apps I've been using .NET Foundation's System.CommandLine [1] recently.
It looks like this Spectre.Console you are using is a bit more fancy albeit a lot newer.
Re: My preferred .NET console stack
#3I too have arrived at Spectre.Console as the best CLI argument handling library.
Aside: I was testing the start-up time of my program last night and discovered that it is being delayed approx. 100ms by Spectre.Console. If any contributors are on this thread, it may be worth looking at start-up performance.
Re: My preferred .NET console stack
#4For F# implementations I suggest https://fsprojects.github.io/Argu/ as the command line argument handling library.
Re: My preferred .NET console stack
#5Spectre.Console looks like a really neat library. I am going to have to check this one out for some of my CLI utilities.
With the advent of Blazor, you could also look at building rich UX on top of the very same business services used in the console variant. I have found that Blazor is productive enough to consider using universally for management/configuration/admin dashboards for whatever business process. You could even have console interface and multiple Blazor apps operating side-by-side within the same logical process. Microsoft's DI & AspNetCore support this kind of thing out of the box.
Re: My preferred .NET console stack
#6For console apps I've been using .NET Foundation's System.CommandLine [1] recently. It looks like this Spectre.Console you are using is a bit more fancy albeit a lot newer. 1 - https://github.com/dotnet/command-line-api/
Yeah, I quite like System.CommandLine.DragonFruit particularly for what should be throwaway test apps, I like the way you just add the parameters into main.
Re: My preferred .NET console stack
#7Dependencies, dependencies, dependencies. All for a simple console program. And you end up with a console app that is 20-100MB. Traditionally this program was a few KB. It can still, if you use the right language(s).
Making software should not be about making the life of the developer as easy as possible, it should be about making things easy, small, and FAST for the user.
Re: My preferred .NET console stack
#8For F# implementations I suggest https://fsprojects.github.io/Argu/ as the command line argument handling library.
[deleted]
Re: My preferred .NET console stack
#9I'm using https://www.nuget.org/packages/CommandLineParser/ for command-line parsing, but found it awkward when handling bools and their defaults are true, then you can't set to false, and in order to do so you have to make them optional, and then your flag becomes: --something=false, not terrible, but not great either, I would've preferred --no-something instead, other than that it serves me well. though would check Spectre.Console too! Thanks!
Re: My preferred .NET console stack
#10Dependencies, dependencies, dependencies. All for a simple console program. And you end up with a console app that is 20-100MB. Traditionally this program was a few KB. It can still, if you use the right language(s). Making software should not be about making the life of the developer as easy as possible, it should be about making things easy, small, and FAST for the user.
Beyond that, the fact that you have to do any of this is silly. The .Net tooling used to be easy, now you’ll be able of building your entire application in python before you’re even done configuring your .Net environment.
I know I’m grossly exaggerating, but the fast movement and the lack of ease of use has been one of the primary reasons to see us slowly move toward python and powershell after nearly two decades of C#. Being a windows happy enterprise org, we still make plenty of use of the .Net family and friends of course, but not really for development.