If the dependencies are written with AOT in mind, otherwise plenty of errors will show up.
Also it isn't that easy if any of GUI frameworks from Microsoft are being used.
Ah, and if using WinUI, one even has the additional requirement that only UI elements implemented with partial classes can be AOT compiled due to WinUI magic code.
I don't know why anyone even uses the GUI frameworks from Microsoft these days. WinForms is only good if you need to throw something together quick. Everything else should be Avalonia (https://avaloniaui.net/). Cross platform and does support AOT.
Good answer to ask Fortune 500 using in office apps, and IT that usually has the policy what matters comes from Microsoft on a full Visual Studio install.
Except most companies are using much more than just BCL.
Your gRPC example is also quite interesting, I am yet to use it in anger, and never seen it being used at any of our .NET customers.
Meanwhile as mentioned, GUI frameworks aren't supported, WinUI requires partial classes and only kind of works, ASP.NET only if using minimal APIs, EF partially, and so on.
So it isn't really telling the whole story that "dotnet publish /p:PublishAot=true" works regardless of the .NET codebase being compiled.
It will be completely standalone. The same way it works with Rust, Go, etc. The binary size will be smaller than Go but bigger than Rust.
Portability is by definition not possible with natively compiled binaries however. It is a choice - either produce an assembly (still single-file, .NET can do this unlike JVM offerings) that is completely portable, or produce a self-contained executable targeted at a particular OS and ISA.
Sure, but not cross-platform, which the previous comment seemed to indicate that GraalVM could, which it cannot. Both tools need to compile on the platform they target, compared to Go/Rust where you can target other platforms even though you're not compiling on them.
Cross compilation is a toolchain feature, not a programming language capability.
As for GraalVM, it has plenty of modes, the AOT one that is being talked about here, is native image.
Which can also use a JAR file as input, so even though it doesn't yet support cross-compilation, you can use the JAR file as single source, and then have a couple of build environments in e.g. Github pipelines.
To the end user it doesn't matter as long as they get their shinny executable available, and it only has to be done once as a project template.
Also note that cross-compiling only really works without issues for whatever compiled language, if the toolchains have access to every single library from the target system on the host environment, and no dependencies FFI into other languages.
I was talking about .NET's publish modes (NativeAOT, portable assembly, etc.).
You are also confusing what it means to produce a portable assembly with the ability to target across operating systems or CPU architectures.
(also, most native toolchains do not let you easily cross-compile, Go makes significant sacrifices to make it possible, as long as you have no dependencies which rely on C/C++, and there are many of those)
