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

.NET 8 Standalone 50% Smaller On Linux

learn.microsoft.com

Post reply on HN
Print view View original

71–80 of 179 posts

Re: .NET 8 Standalone 50% Smaller On Linux

#71

Post by 0xDEADFED5 »

fodkodrasz wrote: post #26
andrewstuart wrote: post #12

Who is using .NET on Linux? I'm interested to hear success stories. Sounds like a a great way to build and deploy applications.

I have good and bad experience as well. I do have a prototype project, and while it allowed to get going quickly, I found the remote debugging story useless, as Visual Studio 2022 SSH support is a steaming pile of garbage. (Doesn't use the windows systemwise ssh install, but some crappy library that only supports password auth, or some wonkny certificate format, and outdated ciphers, which is understandably disabled,…

i just recently switched from VS 2022 remote to VS Code, (windows->linux, C++) and it works very well. i'm not sure i have many reasons to keep VS 2022 around right now

Re: .NET 8 Standalone 50% Smaller On Linux

#72

Post by pansa2 »

2MB for a standalone “Hello World” binary in C# is a similar size to one in Go. Do both languages produce similar-sized binaries for larger projects as well?

If so, would C# be a good choice for writing cross-platform command-line applications?

It seems that C# can produce easily-distributable binaries, while also hitting a sweet-spot in language design - not super complex like C++ or Rust, and also not overly simplistic like C or Go.

Re: .NET 8 Standalone 50% Smaller On Linux

#73

Post by maxlin »

andrewstuart wrote: post #12

Who is using .NET on Linux? I'm interested to hear success stories. Sounds like a a great way to build and deploy applications.

I have a single-file executable with the framework embedded, that I run on all of my computers, from desktops and laptops to cloud VMs to SBC's.

-it's designed to be run once after which it auto-registers itself to always stay running (linux:systemd, windows: task scheduler), while keeping itself up to date

-It contains my CI system (runs software from git, either one run per commit or "keep running forever" mode, UI thru local web server with even browser blazor support hacked in). I use this to run my other programs like servers, crawlers, telegram bots which I write in dotnet and almost always in a way that they run identical on Linux and Windows, x64 or aarch64 (arm). The CI system installs its own dotnet env and env variables to ease with dependencies for the programs ran with it

-It constantly updates its state to a relatively simple azure C# app which functions as a status webpage for all my machines and provides some basic controls like "restart machine" while sending notifications of unexpected machine on/off states

-The executable is capable of automatically updating itself through the central web app server. It does a dance of downloading new version starting the new version as "MRestartor_new", which is then started and renames the current "MRestartor_old", which then starts that "_old" which will rename the newly downloaded one to "MRestartor", then starts that.

-I've half-added a few extra features like remote console, remote VNC-like desktop too

My friend keeps telling me I've re-invented a shitty kubernetes but I actually want to, and need to run this on desktop windows machines (previous reason was Unity build server, now also need it for non-headless puppeteered chrome), and am planning to run some "infoscreen"-like software on it for some computers which would not be possible inside docker to start with.

Outside of this system, I've found the "single file executable" option to be a very pragmatic way to just have a "companion app" bundled with an Unity game for example, that the game starts, and if the game crashes, it sends a crash log. Functions with zero dependencies so even caught an Unity slip-up where Unity actually needed some almost-ubiquitous dll a virgin Windows that our publisher's PC had doesn't actually come with

Re: .NET 8 Standalone 50% Smaller On Linux

#74

Post by supertron »

skrebbel wrote: post #19
andrewstuart wrote: post #12

Who is using .NET on Linux? I'm interested to hear success stories. Sounds like a a great way to build and deploy applications.

I once was CTO of a now defunct startup and we ran a C# backend against a postgres db inside Docker containers on Linux. This was before MS was on board with Linux and all, but Mono was already super good tech. It wasn’t as fast as real .NET but it was still way faster than eg Python or Ruby, the popular backend languages of the day. There was even a half decent cross platform IDE (MonoDevelop), most of the dev team…

You're right, Mono was pretty good even in the very early days. I had a small C# Mono app deployed on macOS in a similar time period (possibly close to 10 years ago now) and I was amazed at how well it worked at the time.

It also felt like magic somehow, after having my .NET development tied to Windows for so long before that...

There were a lot of caveats then and quite some disparity in how it would run on Mono vs normal .NET Framework.

> I assume that if C# on Linux was productive and fast in 2013 it won’t have gotten any worse today.

Safe assumption!

Re: .NET 8 Standalone 50% Smaller On Linux

#75

Post by marwis »

eddythompson80 wrote: post #59
pjmlp wrote: post #41

Earlier quoted context omitted.

Actually many people seem unaware that .NET has supported AOT since the beginning. The reason that they are unaware, mostly is that using NGEN requires really wanting to use it, as it requires dealing with strong named Assemblies, aka signed .NET libraries/executables. It only supports dynamic linking, and still pings back on the JIT for more complex code sequences, its original goal being fast startup time for deskt…

ngen had a lot of problems though. It was very easy to accidentally invalidate it. There was no easy reliable way to "ship" an ngen output. There was no easy way to even check if its even loading. your best option was to run ngen on the target machine, which is fine for services as a deployment step. But it's not like you could build and publish an AOT .NET cli for example.

I think not shipping ngen output was desired. There was an NGen Optimization Service that would reoptimize code when net framework was updated and possibly with new profiling data.

Re: .NET 8 Standalone 50% Smaller On Linux

#76

Post by nevf1 »

viraptor wrote: post #67

I've just tried to move an existing project to this and VS complained that the SDK doesn't support this version, even though I can create new projects with .net8. (preview SDKs are enabled) Is that some real limitation, or is VS being weird here? There's https://marketplace.visualstudio.com/items?itemName=ms-dotne... out there, but I haven't tried it yet.

Hi, you need to make sure you're using "Visual Studio 2022 Preview", not just Visual Studio. Even with "Use Preview SDK's" enabled in the VS2022 tools and options, it will not work unless you have the preview version of Visual Studio installed. You can still create .Net8 projects in Visual Studio, but to build and run them, you will need to do it from the command line (i.e. 'dotnet run').

Re: .NET 8 Standalone 50% Smaller On Linux

#77

Post by criddell »

pansa2 wrote: post #72

2MB for a standalone “Hello World” binary in C# is a similar size to one in Go. Do both languages produce similar-sized binaries for larger projects as well? If so, would C# be a good choice for writing cross-platform command-line applications? It seems that C# can produce easily-distributable binaries, while also hitting a sweet-spot in language design - not super complex like C++ or Rust, and also not overly simpli…

Aside from syntax preferences, why and when would one choose Go over C#?

Re: .NET 8 Standalone 50% Smaller On Linux

#78

Post by viraptor »

nevf1 wrote: post #76
viraptor wrote: post #67

I've just tried to move an existing project to this and VS complained that the SDK doesn't support this version, even though I can create new projects with .net8. (preview SDKs are enabled) Is that some real limitation, or is VS being weird here? There's https://marketplace.visualstudio.com/items?itemName=ms-dotne... out there, but I haven't tried it yet.

Hi, you need to make sure you're using "Visual Studio 2022 Preview ", not just Visual Studio. Even with "Use Preview SDK's" enabled in the VS2022 tools and options, it will not work unless you have the preview version of Visual Studio installed. You can still create .Net8 projects in Visual Studio, but to build and run them, you will need to do it from the command line (i.e. 'dotnet run').

(facepalm) every time I assume that maybe I'm doing something wrong rather than VS being the weird one in the room, they have to prove me wrong...

Re: .NET 8 Standalone 50% Smaller On Linux

#79

Post by throwaway2990 »

sshine wrote: post #65
devjab wrote: post #47

Earlier quoted context omitted.

> Because it’s a great language with amazing tooling. It’s fast, robust, easy to debug, easy to refactor, and so on. I agree but I also think the main issue with this is that you could've said it in reference to most programming languages in 2023. I'm sure people can have a lot of debate on that, but aside from the fast bit, most programming languages are frankly in excellent places today, and fast is sort of irrelev…

I was helping some friends with F# homework, and being a Rust programmer, I had to ask: your project file is XML, and the order you list the project files matter, and it won’t tell you that you listed them wrong? Compile errors are super long lines and don’t show an excerpt of the code with underline under what went wrong with suggestions on how to fix it? I know I’m asking a lot here, but that level is available wit…

> and the order you list the project files matter

What do you mean by this?

Re: .NET 8 Standalone 50% Smaller On Linux

#80

Post by sylens »

criddell wrote: post #77
pansa2 wrote: post #72

2MB for a standalone “Hello World” binary in C# is a similar size to one in Go. Do both languages produce similar-sized binaries for larger projects as well? If so, would C# be a good choice for writing cross-platform command-line applications? It seems that C# can produce easily-distributable binaries, while also hitting a sweet-spot in language design - not super complex like C++ or Rust, and also not overly simpli…

Aside from syntax preferences, why and when would one choose Go over C#?

I have not begun really using Go in earnest yet, but at least in the cloud engineering world it seems to be the language of choice (along with Python) due to the ease of using its concurrency capabilities
Post reply on HN