I tried this. Aot compiling with the .net runtime just isn't very practical. I know mono does this, with some guided info for reflection based classes. But the way the structure is setup, is that string pulls in globalization. And enumeration. And comparable and equality which both work by reflection to pick the right default implementation. Reflection is expected to work, which pulls in all methods and their dependencies. By the time you have a working executable for hello world, you're a few MB ahead. The class library just isn't setup for this kind of use.
I was thinking about this just the other day, when Microsoft announced the latest dotnet 5 preview, and yet again have postponed AOT - Microsoft have been teasing dotnet devs with the promise of production-ready AOT for something like a decade.
Frankly, I wish they'd put up or shut up - either prioritise it and make it happen, or just admit defeat and say it's not going to happen.
It's not really a matter of prioritization. The current WASM platform and toolchain are missing features necessary for AOT-compiling things like .NET executables. For one example, exception filters ... and unfortunately the standard library uses them, not to mention end-user software.
To provide more detail: Exception filters require the ability to stackwalk and search for filters and run them before actually handling the exception. WASM has no stack-walking functionality whatsoever (this also means getting and introspecting stack traces is currently impossible), so searching for filters is already a non-starter. You can try and emulate this through a normal unwind-only exception flow, but you have to rewrite all your application code to insert lots of checks and flow control changes in order to do it, and it's still observably different.
I've spent months just working on fixing this problem, and it's one of the things that wasm AOT is going to need before it can ship.
WASM is a generally weak target platform. A great 1.0, to be sure, but unless your goal is to run posix C code you're going to hit snags. When we were designing WebAssembly to begin with it was an intentional decision for 1.0 to be limited in feature set with the goal of improving it later - a Minimum Viable Product.
Exception filters are also a problem for AOT to non-WASM LLVM targets, for similar reasons - expressing complex exception handling and flow control in LLVM is very difficult. But the situation is better there, at least.
Production ready AOT for .NET exists since Singularity, which MIDL and Bartok compilers were the basis of .NET WinRT on Windows 8/8.x.
Then some of the Midori tech eventually made its way into .NET Native, which from my point of view UWP + .NET Native is what .NET should have been all about back in 2001.
Apparently after the timid attempt with XAML Islands and MSIX, they seem to be getting the house in order and driving the platform into a way to pretend that Windows 8 and 8.1 never happened, but it seems to be lacking a lot of coordination and long term planning.
Windows 10X apparently is also not getting Win32 sandbox any longer, this assuming it ever gets released.
Still in the middle of the chaos, it still feels much better than if I had to deal with Android on daily basis, one IO best practices is next years legacy.
I guess you know this, but what I really meant was AOT for any dotnet apps - not specifically for UWP or whatever sandboxed, designed for touchscreen thing Microsoft is trying to push.
What many have been waiting for is the ability to AOT for both Windows and Linux.
I recall Mono had something like this around 10 years back, but it was a bit flakey. Not sure if that still exists in some form.
I think when someone says "production ready AOT" in any context, it's never quite obvious what they mean. As ckok implied, even when AOT is "working" it may generate a 100mb executable. For some end users that is production ready (like Facebook, who reportedly were shipping 1gb+ AOT'd php executables to their server cluster) and for other end users it is not (because a 100mb browser app is a closed tab.)
WASM now and emscripten before it both were designed and optimized for POSIX C apps and for games, and they're pretty good for those scenarios. Larger-scale stuff is pretty tricky and the tooling ecosystem will have to continue to grow to support more real-world applications. JIT, stackwalking, GC, etc are all still not there on WASM - thankfully threading is finally crossing the finish line but even that has taken years.
