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

91–100 of 119 posts

Re: My preferred .NET console stack

#91

Post by malkia »

oblio wrote: post #64
malkia wrote: post #60

Since you've looked into .NET 5.0 - is it possible now to create a single .exe, and not having to carry extra .dlls (I'm still stuck to .NET Framework 4.7.2 for one reason or another).

It's just a fancy self-extracting archive... it's not a statically linked binary with tree shaking of everything which is not actually used.

ugh - I was expecting something better, then again while probably .NET bytecode maybe more mergeable (Without knowing much about it, assuming "java" like essence), there is still the issue of "pdb" merging (but that should be doable...). Obviously native is problematic.

Back at Google, I really like how this was solved. Bazel (blaze) internally when doing java or python tool - would actually compile the java runner to become the main app, then the .jar (combined) could be part of it (not sure right now, but it could be), and any native C/C++ JVM code would be part of the java runner (all statically linked) - so you end up with single executable.

Same for python - any C/C++ linked externally becomes part of the "python.exe" (sorry, I'm mostly on windows terms now) + the rest of the compiled .python code - may go as .zip with the .exe - or even directly embedded as some data.

I really hope Microsoft goes this way. Distributing single (ok, two with .pdb) executables goes a long way of easing the process - CI, tools, or just here is a tool (to a coworker) that would work for you, and right now is... oh, and you need these extra .dlls (and app.config, and now .dll.recipe files, and who knows what else).

I do really wish .NET comes to realize that single true binary is a must (without temp files extracting, this is so prone to errors, security issues, leaks, etc.)

Re: My preferred .NET console stack

#92

Post by akra »

jackfoxy wrote: post #4

For F# implementations I suggest https://fsprojects.github.io/Argu/ as the command line argument handling library.

I liked Argu when writing .NET in the past. Seemed a lot more feature rich and easier to whip something up than the free alternate C# OSS ones at the time - and IMO looking at this for a typical CLI command app probably still is. Argu's advantage over this, at least it seems to me, is there's a lot less boilerplate (more defaults, less annotations, less classes/files). You could write a solid CLI app with subcommands, etc in a single script if you wanted to. Spectre's advantage seems to be if you want to create an interactive CLI application.

Re: My preferred .NET console stack

#95

Post by ynik »

oblio wrote: post #64
malkia wrote: post #60

Since you've looked into .NET 5.0 - is it possible now to create a single .exe, and not having to carry extra .dlls (I'm still stuck to .NET Framework 4.7.2 for one reason or another).

It's just a fancy self-extracting archive... it's not a statically linked binary with tree shaking of everything which is not actually used.

In .NET Core 3.1 it was a self-extracting archive; I think in .NET 5.0 the assemblies are directly mmapped from the .exe without an extraction step. Also, you can enable some tree shaking: https://docs.microsoft.com/en-us/dotnet/core/deploying/trimm... But tree shaking can be problematic if the application uses Reflection.

Re: My preferred .NET console stack

#96

Post by quickthrower2 »

WarChortle wrote: post #56
AnIdiotOnTheNet wrote: post #25

Earlier quoted context omitted.

They do care, they've just gotten used to bloated software and therefore don't have high expectations. I submit that this is indicative of our failings as an industry.

Not a single non tech person I know has ever complained about the size of an app on download. Not one. They don't even look at the size its not relevant to them. They want to do something that some app enables. Besides how well it lets them do it no one cares about the size until they are out of space, which is usually because they have so many videos and photos stored. You're kidding yourself if you think the averag…

The only case I can think of is mobile apps on slow connections. Even on a fast connection waiting a minute to download an app seems a bit annoying.

Re: My preferred .NET console stack

#97

Post by gnud »

crispyambulance wrote: post #81
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 m…

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.

[0]: http://ndesk.org/Options

Re: My preferred .NET console stack

#99

Post by manigandham »

kertoip_1 wrote: post #67
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.

The biggest issue with it is a really large binaries that have to be downloaded on page start. So it isn't necessarily suitable for use cases where speed matters. But at the same time, it's perfect for dashboards, I really like to work with it.

Server-side Blazor is as fast as any other server-side app, and can prerender the page before the JS adds the websocket connection for interactivity.

Client-side Blazor can also be prerendered now and has much better trimming so you can still see static HTML content instantly while the rest loads up in the background.

Post reply on HN