Announcing .NET 5.0 Preview 7
Today, we’re releasing .NET 5.0 Preview 7. It’s the second to last of the preview releases (before moving to RC). Most features should be very close to done at this point. Single file and ARM64 intrinsics are two feature areas that are taking the longest time to complete, but are on track for Preview 8. See the .NET 5.0 Preview 4 post for a broader view of the release.
ASP.NET Core and EF Core are also being released today.
You can download .NET 5.0 Preview 7, for Windows, macOS, and Linux:
- Installers and binaries
- Container images
- Snap installer
- Release notes
- Known issues
- GitHub issue tracker
You need to use Visual Studio 2019 16.7 to use .NET 5.0. .NET 5.0 is now supported with Visual Studio for Mac. Install the latest version of the C# extension to use .NET 5.0 with Visual Studio Code.
Stephen Toub recently posted his Performance Improvements in .NET 5 post, the latest in his series. He covers ~250 performance-oriented pull requests, which reveal improvements that will even surprise people who follow .NET Core performance closely.
We’ve been adding usability feature to the new JSON API. The following features are new in Preview 7 (more coming in Preview 8, too).
- [Breaking change] Ability to ignore default values for value-type properties when serializing — can be used to reduce serialization and wire costs.
- Ability to handle circular references when serializing — API shape is now expected to be final.
Garbage Collection (GC)
The GC now exposes detailed information of the most recent collection, via the GC.GetGCMemoryInfo method, which returns a GCMemoryInfo struct. GCMemoryInfo provides information about machine memory, heap memory and the most recent collection, or most recent collection of the kind of GC you specify – ephemeral, full blocking or background GC.
The most likely use cases for using this new API are for logging/monitoring or to indicate to a loader balancer that a machine should be taken out of rotation to request a full GC. It could also be used to avoid container hard-limits by reducing the size of caches.
Another, small but impactful change, was made to defer the expensive
reset memory operation to low-memory situations. We expect these
changes in policy to lower the GC latency (and GC CPU usage in general).
RyuJIT is the assembly code generator for .NET, target both Intel and ARM chips. Most of the investment in RyuJIT is focused on performance.
- General Improvements
- Enable eliding some bounds checks — Credit @nathan-moore
- Optimize Enum.CompareTo after being rewritten in C# — performance is now at parity with previous C++ implementation.
- Improvement in register allocation for structs — Enregister multireg lclVars
- Improvements for removal of redundant zero inits
- Tail duplication improvement
- Stack based structs copy CQ fix
- Clean up a dead field assignment after removing redundant zero initializations
- ARM64 hardware intrinsics & API optimization
- Implement majority of “by element” intrinsics
- Implement fcvtxn, fcvtxn2, sqabs, sqneg, suqadd, usqadd intrinsics — #38010, #38110
- Optimize SpanHelpers.IndexOf(byte), SpanHelpers.IndexOf(char)
- Optimize SpanHelpers.IndexOfAny(byte)
- Optimize WithLower, WithUpper, Create, AsInt64, AsUInt64, AsDouble
- Optimize AsVector, AsVector128, GetUpper, As and WithElement
Please tell us about your experience using Preview 7. It’s not too late to share your feedback. We are getting close to the end of the release, but are actually more focused on quality now since we are largely done with feature development.
After Preview 8, we plan to release two RCs before the final release. The RCs will have “go live” licenses, meaning they’ll be supported in production. On that note, we’ve been running the dot.net site on .NET 5.0 since Preview 1 (50% on 5.0; 50% on 3.1) and it has worked great.
Still no mentions of AOT?
I’ll be posting more about our single file project in the Preview 8 or RC1 post. The project has been more complicated than expected. That’s the reason for the delay. The delay is not due to AOT, but the single file nature of the project. You can see what we’re up to on GitHub @ https://github.com/dotnet/runtime/issues/36590
The AOT part continues to be based on generating ready-to-run images. This is very similar to what you can use today with .NET Core 3.1. The combination of AOT, single file and a more linkable framework make the overall result much better.
I don’t think this answers the question as AOT compilation is compilation to machine code. Ready-to-run images, if they are a continuation of the existing approach, contain IL as far as I can tell. That’s not AOT compilation; it’s something very partial.
AOT in .Net 5:
– No clear plan for maintaining AOT in UWP apps with .Net 5 (gong backwards compared to .Net Native)
– No release of iOS/Android which would allow .Net 5 using monovm AOT (stagnant)
– No improvement on WPF compared to the ancient Ngen (stagnant) . “R2R by design principle will always be a bit slower than fragile native images” suggests that R2R is only appropriate in niche scenarios where versioning is a big problem.
The more I see the promotion of things like R2R the more it’s clear that there is no sensible short-term plan.
Productizing CoreRT for and making it usable in UWP and WPF would go a long way to adressing the immediate problems.
This is bad news. I’ve expected AOT to be more like CoreRT (full native compilation) than R2R/NGEN…
And they didn’t even manage to make single file to be truly single file on Windows, because there’s still 4 DLL’s that are not linked statically…
Found https://github.com/dotnet/runtimelab/tree/NativeAOT that seems to be based on CoreRT, but that’s definitely not something that will be ready for .NET 5.0 release…
Oh boy… this is heavily disappointing. We have NGEN und ready-to-run for quite a while now. While they somehow give performance benefits they still don’t solve a loooong issue we have with JIT code, which is STILL be used in all of these scenarios: Protection of intellectual property. Every .NET application can be opened by decompilers and fully reveal the source code (technically its not 100% the identical source code but lets keep this detail out for now). Even all variable and method names remain.
I’ve expected something like Mono’s IL2CPP which turns ALL code in completely native code, getting rid of IL completely. Completely impossible to decompile. Completely native with all its benefits, like performance.
What I’ve not expected is that AOT will be something like ready-to-run bloating up the application size by shipping native code next to IL code for a somehow performance boost and that’s it. In this case, AOT will not be game changer.
You might be living in a fantasy world. Native code isn’t impossible to decompile. If there’s no metadata, you’ll get ugly generated function and variable symbols which is often what happens when you decompile a C program but dotnet has reflection and a ton of metadata related to that so you should be able get most of the symbols, too. Either way, it’s decompilable even if there isn’t currently an app that does it. As soon as a significant number of projects start leaning on that for obfsucation, there will be one written. Possibly sooner if some hobbyist decides to do it for fun without any cost/benefit analysis.
.Net native has limited metadata and limited reflection support. In mono AOT the linker will strip a lot of metadata.
True AOT modes have limited or no support for reflection, and there is progress in mono/linker which will be moved to dotnet/runtime to have attributes for linkers and reflection-limited environments to indicate when to preserve code and metadata. The problem is this progress is very slow, while the removal of .Net Native is a dramatic regression.
There is no AOT？
Golang, I’m here~~~~！
It’s really disappointing. You guys made a big plan last year and finish a part of it. AOT is a big deal. No AOT would cause lots of developers give up dotnet. As far as Internet, Mobile Internet, Big Data, Cloud Computing, AI and IOT, which one is dotnet playing key role in? Where are you going to take dotnet to?
Your team cannot be trusted, you kept being evasive/ignoring questions related to AOT, then you finally spoke with .net 5 preview 5 saying we’ll hear more about AOT for preview 7, here is preview 7 and not a single word about AOT
Good job! /s
Richard LanderMicrosoft logo June 10, 2020 5:07 pmcollapse this comment comment link
We will have more to say about AOT and single file, for preview 7.
AFAIK AOT was postponed in .Net 6.0 because it was too much work to refine it enough to be commonly supported in .Net 5.0 (which is already packed with Blazor and Perf improvements). It was announced month ago I think. You can still use AOT (check the repo “dotnet/corert”) and it IS actively developed by the .Net Team but it’s not mature enough. Yet, it is used in varied products (like some games released on XBox & Windows Store) without much problems so you can too if you want. Just don’t expect MS support 🙂
For the Single File it is delayed to the next released, well at least it’s confirmed.
That’s what we use already, CoreRT project, we are very happy with it, but it’s hard to plan our next project with it if its future at microsoft is not clear, it’s hard to trust microsoft these days, just look at how they managed to talk about AOT just to give us a poor-man’s solution aka R2R..
I don’t understand why they are so evasive on this subject.. what’s going on?
From what they say here in comments and in GH issues, it seems that several implementation of AoT are being discussed internally and they haven’t reached a conclusion. There indeed quite a few constrains to consider, in the same way that the Single File solution have changed a few time over the year because of different expectations (it started as a non multi-platform self extracting solution to a in memory multi-platform one as I understand it).
Let’s hope they postponed AoT because they want to go for the most ambitious (compatible/performant/easy to use…) solution!
I just wanted to compliment the team and say, Keep up the great work. Engineering is tough, to accomplish great things you need to make big goals and take great risks. Once WinUI pulls together I am going to be excited to finally have all of the tools I need to write amazing applications.
this comment has been deleted.
AOT is a big deal , if no AOT in Dot Net Core 5 then bye bye dot net 🙁
Again a disappointing preview. .NET 5 Preview 7 is nearly nothing more than .NET Core 3.1 with performance updates, bugfixes and more API reloads. All those anticipated new features listed in the roadmap are unlimitedly put off without any explanation, and even complaints are ignored and skewed. The AOT that was widely asked and expected as some solution like stabilized CoreRT, is ridiculously answered as R2R and single file publish. How come?
Totally agreed. Even ptomised WinForms designer will not be ready for 5.0 🙁
aot and hybrid run mode in coreclr, please
Any info about Xamarin integration? Will Xamarin apps (i.e. Android, iOS, macOS) use .NET5 instead of Mono?
Very excited with this release and with Blazor already using .net 5! very good work!
Regarding what everyone is saying about AOT.
.NET Native + UWP is all .NET should have been all along since 2001, instead of jumping into Java’s marketing and J++ ashes.
It was what I as long time Object Pascal fanboy was expecting from C# linage.
After projects like Singularity and Midori that never made it into mainstream Windows, we got the MIDL attempt and then finally .NET Native seemed it was going to be it, we were getting .NET done right as it should have been to start with.
With recently announced Project Reunion, unclear AOT roadmap, and focus of classical .NET/Win32, the underlying message seems to be to re-focus on how things were, before this whole WinRT idea started and it is time to clean up the house.
Sorry if I am being unfair given the wonderful work on .NET 5 runtime improvements, but that is how things look from the outside.
Yep. UWP would actually be a good alternative to the poor future of AOT in .NET/Win32 except of two reasons:
It’s Windows 10 only. This was a big issue but nowadays even bigger companies upgraded to Windows 10 and Windows 7 finally reached its (final) end. So this issue has been solved.
Its sandboxed an you cannot distribute it as a single portable file. This is the only reason why I’m still working with WPF (which is obviously dead. The roadmap only shows a “we will fix bugs only” similar to .NET Framework but no real development in bringing new features etc.) or Winforms which is fine for some projects but nothing fresh here as well.
Projects like WinUI are clearly UWP focused. There is some partially support for Win32 but its more like a XAML Island copy which only embeds UWP controls and causing several issues as you cannot fully control the UWP control in your Win32 application. Just saying the media player in UWP has an aspect ratio property. The Xaml Island / WinUI media player for Win32 however does not give access to it. Has been reported since months. Anyway back to topic, for Windows UWP and Xamarin seems to be Microsoft answer for the future, everything else is in maintenance mode. But UWP is still not a choice because of the reasons above and Xamarin Forms are mostly for macOS and mobile… experience on Windows Desktop is terrible.
When .NET 5 was announced it looked like they’ve having a plan. Things getting simplified and unified and we will get game changers like AOT. They’re really having the rights thoughts… but the end result is not what the community has expected as most of the time, it’s just something in the middle. Something we have seen before, just with a new name and some minor changes. When a full multi-OS UI was announced people didn’t expect its just a rename of Xamarin Forms, as Xamarin Forms still has its own big issues, which won’t go away just because it has a new name on it. When AOT was announced people didn’t expect its just the existing ready-to-run. There are many good existing things in the .NET world, why don’t just take the good stuff and remove their limitations? Allow UWP portable and unsandboxed? Allow mono’s il2cpp on .NET 5? Rewrite the last closed source Windows only stuff in WPF and make it cross plattform?
I agree, and regarding WPF it is not only the roadmap, WPF got dumped into a completely new team and we all know from experience what happens when Microsoft products kept getting thrown across teams like hot potatoes.
So now we have Forms, WPF, WinUI, UWP, MAUI, Blazor, plus soar taste from unclear AOT, dropped WCF, EF 6 VS tooling, Managed DirectX, XNA, Silverlight,….
A Project Reunion that appears to be cleaning the house, but without clear roadmap of what it actually means.
And for those of us that need to deal with C++ because Windows team refuses to make APIs like DirectX accessible via WinRT, after killing wrappers like XNA, we got C++/CX taken away, replaced by C++/WinRT with lesser tooling, where we have to manually copy files around and manually edit IDL files, like back in the ATL days.
Ranting here, and being very unfair for the teams that actually put the work into improving .NET, but if reading this, please give us a proper consistent message, stop killing tools and have a roadmap that doesn’t keep changing all the time.
Can’t agree more.
Would it be possible to go into why the .NET 5 runtime-dependent DLL for Windows is the same size as the .NET Framework binary, whilst the .NET 5 runtime-dependent binary for Windows is 28 times larger than the .NET Framework equivalent, as well as the .NET 5 DLL? Why is a simple wrapper that should effectively just embed the DLL and run “dotnet dll” on the embedded library 140kb when similar wrappers have been 5kb or smaller in the past?
.NET Framework EXEs are understood by the Windows loader. The loader then calls into mscoree.dll, which then loads the runtime. All of the runtime loading logic is not the in the EXE.
.NET Core EXEs do not have special treatment in Windows (or any other OS). They have to handle runtime discovery and loading themselves.
That’s the difference.
Seeing as how you’re specifically compiling FOR Windows in this case, is there any reason that the binary would not offload its calls to the native OS as it does in the .NET Framework? For standalone – Sure – But for runtime-dependant and compiling for a specific OS?
As it stands, one could simply code a minute C/C++ wrapper that simply wraps the Framework-sized Core DLL in a C/C++ EXE that calls dotnet on it when run, thereby reducing the size of the EXE to approximately 1/25th its current file size as well as maintaining the execution speed of the native .NET Core code.
An odd workaround to retain Framework-sized EXE’s with Core-speed code for sure, but it would work :/
Runtime-dependent DLL could be moved to an MSIX solution with framework packaging — it’d be nice to get some feedback on that issue on GitHub. Both a desktop bridge MSIX and a UWP MSIX could benefit from framework packaging, as best as I understand it.