Comment by cachius
3 months ago
You might want to read https://learn.microsoft.com/en-us/dotnet/core/deploying/nati...
Publishing your app as Native AOT produces an app that's self-contained and that has been ahead-of-time (AOT) compiled to native code. Native AOT apps have faster startup time and smaller memory footprints. These apps can run on machines that don't have the .NET runtime installed.
There are quite a few gotchas for this, especially web apps. THis is understandable because it was added after the fact, vs. a first-party design requirement. It's cool and might work for you, but taking a non-trivial .net codebase to native AOT can be tough, and if you're starting greenfield, why go .net?
FWIW, the .net folks seem to have put a lot of effort into the native AOT pipeline in the last few releases. We have a large, non-trivial application with a fair amount of legacy code, and getting it AOT’d in .net 10 (targeting wasm, even!) was not an insane lift.
How is the WASM target looking nowadays? I tried it in 2023 and early 2024, and it was far from complete (JS interop, poor documentation scattered across GitHub issues, and so on). I still can't find a single trustworthy source of documentation on how to proceed. C# would look great at the edge (Cloudflare Workers).
Sure, legacy applications won't be easy to move over but Microsoft has been quite consistent in working towards making microservice applications easy to build and run with AOT by moving more and more components over to using source-generators and promoting minimal-API's.
Their target is probably not entirely greenfield projects (although I wouldn't mind it myself), but rather those with existing investments that start new projects that still want to share some parts.
And this sounds great until you get to the laundry list of restrictions. For us the showstopper was you can't use reflection.
You can't use reflection with AOT compilation. That's what AOT compilation is. Java has the same limitation for AOT compilation, for example.
Most reflection usage is for JSON (de)serialization and for that you can use source generators, which also offer better performance.
https://learn.microsoft.com/en-us/dotnet/standard/serializat...
These same restrictions exist for Go, the Go team just decided that it was easier to never support these features to begin with which has its pros and cons.
Such as? For the ones I've actually needed from the C# AOT limitations list, you can use reflection and dynamic loading just fine in Golang, with static single-binary compilation and all.
2 replies →
They're self contained and native, but they're still massive.
There's been some work on CoreRT and a general thrust to remove all dependencies on any reflection (so that all metadata can be stripped) and to get tree-shaking working (e.g. in Blazor WASM).
It seems like in general they're going in this direction.
Smaller is better, of course, but I've never found the size of .NET binaries to be an issue.
What problems does this cause?
If you're trying to pack hundreds of microservices into a cluster, having containers using 80MB of ram minimum instead of 500KB can become a big deal.
Not every library is capable of building to Native AOT, which means any app that depends on those libraries run into the same problem. If the library or app uses reflection, it likely isn't capable of Native AOT compilation.