Jeezus, that's a lot of code to get a decent console. On Mac I just install iTerm. Does everything have to be long-winded and verbose with C#?
This is code to write a command line application, not to use the console.
My preferred .NET console stack
111–119 of 119 posts
Re: My preferred .NET console stack
#112> public thing Thing = new Thing(); can we please please please stop making programming languages like this
One time C++ is more terse:
public:
Thing thing
:) Really though this is just the old way to write C#. Even Java is starting to update this pattern.
Re: My preferred .NET console stack
#113Earlier 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.
Second this. Want to use blazor but worried they are going to pull the rug out from under us, siverlight anyone (smile)
Always a possibility but seems unlikely based on the efforts and cross-platform story that Blazor brings in.
Silverlight required add-ons for all platforms to be pre-installed. That was too similar to Flash and Silvelight became obsolete as soon as these plug-ins were not going to be supported on iPad and iPhones. There was no real point anymore.
At this stage, I see Blazor as a necessity for the .Net platform to move forward on being relevant for apps that require UI. There is no real official .Net cross-platform way of building complex user interfaces.
Blazor has the advantage of being a platform on which MS can build on to bring all types of apps together: they can be OS agnostic (.NET 5.0 already runs on Win, Mac and Linux) and target web, desktop and mobile in one swoop, although it will require a few iterations to have an ecosystem rich and stable enough to work well and consistently everywhere.
Re: My preferred .NET console stack
#114Since 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).
There will be some required .dlls with your .exe. The size of .exe for a simple console app is around 60 Mb.
Re: My preferred .NET console stack
#115Dependencies, 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.
> And you end up with a console app that is 20-100MB What are you talking about? It's 1.4MB. This is the easiest thing in the world to verify: $ 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... All projects are up-to-date for restore. ConsoleApp -> /tmp/ConsoleApp/bin/Release/net5.0/Conso…
You may well be right for Windows. However, many command line tools need to be cross-platform, and in that situation (especially on Linux) the .NET framework/runtime very likely won't be installed.
Unless you are only doing Windows tooling, you probably do need to bear that in mind.
Re: My preferred .NET console stack
#116Earlier quoted context omitted.
> The .Net tooling used to be easy Net tooling used to be horror. Now its good. Speaking as someone who does CI/CD work on it for a long time. You seem to speak as someone who doesn't have .net muscle memory. Programming is complex, unless you finish with hello world (even hello world is complex in enterprise environments).
He's probably looking at it from a different angle. As someone who has had to set up MSBuild & other BS for a CI server, I definitely agree with you. For a dev used to double click Visual Studio, the current setups are more complex.
Indeed.
If 'it works on my computer' is a measure, then pre dot.net core era is as good as it can get.
Re: My preferred .NET console stack
#117Earlier quoted context omitted.
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?
It's a bigger unit than a "(user) story" in agile development.
Re: My preferred .NET console stack
#118Earlier quoted context omitted.
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.
> But tree shaking can be problematic if the application uses Reflection.
Reflection is common.
Re: My preferred .NET console stack
#119Earlier quoted context omitted.
He's probably looking at it from a different angle. As someone who has had to set up MSBuild & other BS for a CI server, I definitely agree with you. For a dev used to double click Visual Studio, the current setups are more complex.
Indeed. If 'it works on my computer' is a measure, then pre dot.net core era is as good as it can get.
Except it isn't. We obviously had setups that mirrored production long before docker and CI/CD became a thing, but spending time configuring those things, for every project is just insane.
Even pythons virtual environments take less time to use than .NET.
Sure I actually liked the "double click" thing in Visual Studio, but that had nothing to do with "if it works on my computer", it simply saved bundles of time because we'd publish every project to the same damn IIS instance and not have them all run their independant web-servers with their independant setups.
Hell we still put things behind the same damn IIS instance and it's load balancer and all that, because why wouldn't we? We're not Netflix, we don't need to scale to two billion people. Our max load is 50.000 concurrent users, yet our build load and our deployment pipeline is now so best-practice, SOLIDVOLID, Buzzworded, CONSOLELIEK and complicated might actually work for Netflix with enough iron.
What's worse is that, it's now your job. Not the operations dude who actually specialize in this, no yours, along with keeping up with you know, actual programming.
Being the public sector, we benchmark everything, and the things we don't benchmark we hire E&Y to benchmark, and you know what our most expensive resource has seen the biggest increase of their time going into over the past 30 years? Configuring and maintaining their tooling. Not developing new things that are useful for our actual business, no sir, but working with the tools that allow them to develop things. It's up by 130% compared to 1998.
I'm not sure what you'd call that inside big-tech, but in non-tech, we tend to call that, a waste of resources.
At least we can lower the cost by vendor-lock-in with azure, right?