Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

My preferred .NET console stack

devlead.se

Post reply on HN
Print view View original

81–90 of 119 posts

Re: My preferred .NET console stack

#81

Post by crispyambulance »

hacker_9 wrote: post #16

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.

Re: My preferred .NET console stack

#82

Post by canadianfella »

ripley12 wrote: post #41
nend wrote: post #30

Earlier quoted context omitted.

Blazor is still a bit rough around the edges but I find it so promising. I really hope Microsoft whole heartedly embraces it for front end development.

Have you seen the Blazor work planned for .NET 6? Hot reload and desktop apps with Blazor UI are both priority-0 (ultra-high priority) epics, I'm really looking forward to it. https://themesof.net/

What is an epic?

Re: My preferred .NET console stack

#83

Post by Rapzid »

watermelon0 wrote: post #36
erikbye wrote: post #14

Earlier quoted context omitted.

> Very few users care at all about the size of an app That depends on the target audience. IME the target audience of console/CLI programs are more likely to care about size. CLI apps tend to cater more to power users. And many users do definitely care about resource usage, and smaller size apps do in fact tend to use less resources. All users definitely care about performance. A fast app feels nicer. Smaller-sized s…

I deeply care about performant and small apps. I definitely don't want to have 100GB+ games on my disk, 150MB+ Electron based messaging apps, Docker images with 1GB+ node_modules/ folders, or even worse, Docker images with 600MB+ of binaries (looking at Terraform and it's plugins.) However, I care even more about having apps/tools that help me achieve the desired goals, in an easy, clear, and elegant way. If having b…

On a tangentially related note. Apparently the huge game sizes are on purpose these days. With downloads and storage so fast and cheap the developers ship assets in a format optimized for the in-game experience instead of space savings. Better to use more space and reduce the initial startup and loading times.

Contrast this with a game like Detroit.. It took my system(5700 XT and 3950x) what seemed like nearly 30 minutes to arrive at the menu screen due to having to compile all the shaders and who knows what else. I'm sure there were other considerations there, but still..

Re: My preferred .NET console stack

#84

Post by bluefirebrand »

hacker_9 wrote: post #16

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.

As a non-.Net developer, my impression of anything .Net is always a hefty amount of boilerplate.

Re: My preferred .NET console stack

#86

Post by hannasm »

I prefer referencing PowerShell and implementing commandlents. system.management.automation.pscmdlet

I don't see a whole lot of developers familiar with this package but it is great if you can see yourself using PowerShell or a batch file wrapped to invoke it. No boilerplate, no parsing, auto generated help and type safe validations.

Re: My preferred .NET console stack

#87

Post by Arnavion »

SideburnsOfDoom wrote: post #58
erikbye wrote: post #21

Earlier quoted context omitted.

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:\Progr…

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.)

Re: My preferred .NET console stack

#88

Post by SideburnsOfDoom »

Arnavion wrote: post #87
SideburnsOfDoom wrote: post #58

Earlier quoted context omitted.

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:\Progr…

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 run…

My example may not be the best, but .NET Commandline handling libraries contain significant quote-handline code. I know because I have relied on it.

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

Re: My preferred .NET console stack

#89

Post by bob1029 »

bradford wrote: post #45
hacker_9 wrote: post #16

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.

> 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 pro…

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.

Re: My preferred .NET console stack

#90

Post by [deleted] »

lol768 wrote: post #51
erikbye wrote: post #40

Earlier quoted context omitted.

> And no, I don't want to hear about any figures for self-contained builds. Then what is your point? When talking about the size required for a program to run, you have to weigh all of its dependencies. For anyone interested, such a binary ends up at least 50MB, if we include the dependencies mentioned in the article in question.

> For anyone interested, such a binary ends up at least 50MB .. if you don't make any use of assembly optimisation/trimming, sure. $ dotnet publish -c Release Microsoft (R) Build Engine version 16.8.3+39993bd9d for .NET Copyright (C) Microsoft Corporation. All rights reserved. Determining projects to restore... Restored /tmp/ConsoleApp/ConsoleApp.csproj (in 18.97 sec). ConsoleApp -> /tmp/ConsoleApp/bin/Release/net5.0…

[deleted]
Post reply on HN