Hacker News new | ask | show | jobs
by pjmlp 2214 days ago
Unfortunately .NET Native seems to be on the way out with the project Project Reunion, and it is not clear how AOT support will be like post NET 5 release.

So far they are demoing single file release, which is basically packing everything into the same exe, but you get a JIT + MSIL instead.

2 comments

I agree. .NET Native was always for the full framework only; I think CoreRT was supposed to be the future there but it seems to be put by the wayside now as with .NET Core 3 the official recommendation for AOT was Mono with no mention of CoreRT in the roadmap. I would love to hear from Miguel what the plans are there.

Ironically this comes at the same time that C# the language has become much more usable without GC or with minimal GC thanks to the work that went into implementing Span but I think that was more a matter of necessity to support advanced async features for web usage (although I found it also made P/Invoke a joy and eliminated virtually all my need for marshaling in a few codebases.. and would have eliminated all the performance issues the led the OS team to abandon C#). It does seem that the ASP/Blazor team is driving the show and calling the shots after the UWP failure in terms of adoption, and I’m not seeing too much that would indicate it’s not the case even with Project Reunion. I’ve been testing WinUI 3, MSIX, and WebView2 and have been disappointed at the lack of story for putting all the parts together. It seems like side-loading packages with sparse package projects is intended to replace “native” UWP packages (“regular” AppX packages require .NET native unless side-loaded and I can’t get apps pulling in WinUI/STJ/Buffers/etc code to compile to .NET Native without an undeclared dependency on System.Private.CoreLib and without serious hacks to enable RTTI which makes me think they’re not meant to be used in that way any longer) but as always MS isn’t very forthcoming about the future of UWP components more than a single step at a time with all bets clearly hedged.

In C# 9 there will be Source Generators, an easy way to generate code in a build task before compilation. That will remove the need for Reflection in many areas. Work is also underway to identify and remove all "linker" dangerous code. Once the SDK is linker safe and has a lot less reflection, AOT becomes a lot easier.

Mono is now part of the dotnet family so I suspect they are going to use that for AOT in C# forwards. Starting with Blazor.

The low level stuff seems to have come from three fronts, high performance Web servers (trying to be on top results at TechEmpower), improving overall performance for Unity/MonoGame/Xenko, and given their position regarding safer languages, reducing the need to jump into C++/CLI for performance.

Project Reunion seems to be the start of long roadmap to bring UWP tech into Win32, as if Windows 8 had introduced UWP as Win32 evolution without the additional application model.

So if developers don't migrate en masse into UWP, bring UWP APIs (COM v2) to all Windows developers and in 10 years from now pretend that Windows 8.x (UAP)/W10 UWP never happened.

I used to believe in UWP despite all its issues, still think C++/CX was the closest that Microsoft ever came to having their own C++ Builder (C++/WinRT tooling is still too clunky), and .NET Native was what .NET should have been since day one.

Oh, well lets see how all of this will turn out.

IL2CPP won't come to .NET Core world?
IL2CPP is Unity product and designed to work together with their new B̶l̶a̶z̶o̶r̶ Burst compiler toolchain.

It is quite different than a general purpose AOT compiler for .NET, as it also takes into account HPC# code patterns.

I'm not 100% on this, but I'm pretty sure that HPC# has a separate, LLVM-based compiler.
Unless something has changed, Burst also uses IL2CPP.

https://docs.unity3d.com/Packages/com.unity.burst@1.3/manual...

As far as I can see, if it's AOT compiled it requires the same linker tooling as IL2CPP does, but is otherwise separate from it.

https://docs.unity3d.com/Packages/com.unity.burst@1.3/manual...