I might be missing a joke? but they are referring to NativeAOT, aptly named as it compiles a .NET application into a native binary ahead of time (instead of using a JIT.) The benefit being no dependency on the .NET runtime, faster startup time (but slower runtime performance, due to lack of JIT), lower memory footprint, and any other advantage you’d find in Go.
The question is, how good is NativeAOT comparable to a static binary from C++ or Go? As we both know Microsoft has a very poor track record when it comes to static builds / “self-contained” stuff. My question was mostly satire but I still would like to know how “self-containted” are those applications.
Does it effectively output a single binary? Does it create some kind of clusterf*k and awkward packaging formats like other MS solutions such as UWP? Will it actually be deployable to a random fresh install of Debian 12 or Windows 10? What about compatibility with older systems?
Not sure about that, I suppose it depends on the targets each .NET version support. For example, .NET 8 will drop RHEL 7 and only RHEL 8 and later.
And to play devil’s advocate: this won’t work for all existing .NET applications. If you use reflection (which is AOT unfriendly), chances are that you will have to rework a ton of stuff in order to get to a point where NativeAOT works. There’s a middle solution though, called ReadyToRun, which has some advantages compared to running fully with the JIT compiler.
Thank you for the link, so --self-contained will results in “a folder that has our exe and everything that is required to run it (…) a little over 200 files” while /p:PublishSingleFile=true will result in a 70MB file for a simple hello world. This kind of confirms my cheap satire :D it is nice this is an option now but the mess and size is crazy. Statically built Qt programs for Windows, with a GUI, are usually around 10MB for a simple app.
I’m pretty sure that 70MB is including the entire .NET standard library, which is massive. Enabling NativeAOT or trimming reduces the size down to a few MB
I just don’t get the obsession with small executable file sizes. 100 MB here and there hasn’t mattered at all in desktop development for many years. Feels like arbitrary goals set up just to be able to say “look there are still uses for [unmanaged language]”. And of course there are, but a 60 MB smaller executables on a desktop with several terabytes of storage just isn’t one of them. And no, developer, about to comment about how you’ve only got 5 millibits of storage on your embedded system, we’re not talking about that.
I might be missing a joke? but they are referring to NativeAOT, aptly named as it compiles a .NET application into a native binary ahead of time (instead of using a JIT.) The benefit being no dependency on the .NET runtime, faster startup time (but slower runtime performance, due to lack of JIT), lower memory footprint, and any other advantage you’d find in Go.
The question is, how good is NativeAOT comparable to a static binary from C++ or Go? As we both know Microsoft has a very poor track record when it comes to static builds / “self-contained” stuff. My question was mostly satire but I still would like to know how “self-containted” are those applications.
Does it effectively output a single binary? Does it create some kind of clusterf*k and awkward packaging formats like other MS solutions such as UWP? Will it actually be deployable to a random fresh install of Debian 12 or Windows 10? What about compatibility with older systems?
Yes, that’s one of the points of NativeAOT, a self-contained single binary, exactly as Go does it.
No, you can create .exe files.
Yes, NativeAOT supports Windows, Linux and MacOS, x64 and Arm64.
Not sure about that, I suppose it depends on the targets each .NET version support. For example, .NET 8 will drop RHEL 7 and only RHEL 8 and later.
And to play devil’s advocate: this won’t work for all existing .NET applications. If you use reflection (which is AOT unfriendly), chances are that you will have to rework a ton of stuff in order to get to a point where NativeAOT works. There’s a middle solution though, called ReadyToRun, which has some advantages compared to running fully with the JIT compiler.
Thank you for the link, so
--self-containedwill results in “a folder that has our exe and everything that is required to run it (…) a little over 200 files” while/p:PublishSingleFile=truewill result in a 70MB file for a simple hello world. This kind of confirms my cheap satire :D it is nice this is an option now but the mess and size is crazy. Statically built Qt programs for Windows, with a GUI, are usually around 10MB for a simple app.I’m pretty sure that 70MB is including the entire .NET standard library, which is massive. Enabling NativeAOT or trimming reduces the size down to a few MB
My bad, the link I sent was not about NativeAOT, just bundling all the dependencies together (also, it’s 4 years old). After a quick search, here’s a recent SO question that mentions that you can build .exe files
As for the filesize… please recheck the post under which we are commenting. :D
I just don’t get the obsession with small executable file sizes. 100 MB here and there hasn’t mattered at all in desktop development for many years. Feels like arbitrary goals set up just to be able to say “look there are still uses for [unmanaged language]”. And of course there are, but a 60 MB smaller executables on a desktop with several terabytes of storage just isn’t one of them. And no, developer, about to comment about how you’ve only got 5 millibits of storage on your embedded system, we’re not talking about that.
Simple, larger binaries = more time to load into memory. Why over complicate things that could’ve been made way simpler?
It’s a single executable that runs with no dependencies.