Exactly. To add to this, is called ahead-of-time compilation, and bundles required parts of the .net runtime into the single-binary. Deployment targets thus don't need to ship any .net environment or libraries.
AOT is entirely independent of single file binaries. And self-contained binaries that run without the framework installed are again a separate concept. There are some dependencies between these, but they are not the same thing.
AOT is not all that useful yet for many applications as important libraries still don't support it. So more something for things like CLI tools with a small scope.
It's not quite the same as with Go, the binaries get large if you can't trim them. But creating single-file self-contained executables is very much usable and works well otherwise.
> AOT is entirely independent of single file binaries.
splitting hairs, but its is not independent. AoT is a required pre-requisite for single-binary creation. You can't create single-binaries with JIT. And that is the big hurdle, lot of libraries do not support AoT and that is the blocker to create single-file binary. Once you have the AoT figured out, the single-binary creation is easy.
Yes, you can. I am using that in production right now. An ASP.NET Core application as a self-contained single-file binary, without AOT.
.NET AOT right now is a very specialized solution that isn't widely applicable. Self-contained and single-file binaries do work pretty much out of the box already.
See the documention here for the PublishSingleFile and SelfContained options:
Yes but no. It's essentially a self-extracting executable, so adds significant start-up time. It also doesn't work in all cases, for example the database driver files to the DB we use aren't compatible with the single-file deployment method.