![Rich Lander [MSFT]](https://devblogs.microsoft.com/dotnet/wp-content/uploads/sites/10/letter-avatar/cb895f2fa6fae6447bab144d4f3ec4b3.svg){kind=avatar}
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.
Performance
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.
System.Text.Json
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
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
Closing
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.
![Sourabh Shirhatti [MSFT]](https://devblogs.microsoft.com/dotnet/wp-content/uploads/sites/10/letter-avatar/9228d33c03603017171cd81a0ce66d32.svg){kind=avatar}
.net 5's performance improvements have been shocking. It's the single biggest performance jump I've seen in my 35 years in the industry.
For instance, my Binaron.Serializer https://github.com/zachsaw/Binaron.Serializer/ improved by 23% just by switching from .net 3.1 to 5!
In our company's proprietary high performance document search engine (similar to elasticsearch but with different feature sets), it gained a 17% improvement in its normal workload. That is crazy.
Lucky you. I’m actually seeing regressions in my code (heavy in maths). It seems they have reached the point of diminishing returns.
AOT is important!
NETCORE is later than openjdk and lags behind Java.
Now I’m going to fall behind again to golang. Nice work!
What about VB.NET? It will be supported again?
Is there going to be an Alpine (or generic musl) SDK for arm64? There's a runtime but no SDK. There is an x64 runtime and SDK but that doesn't do me any good. Attempting to build from dotnet/installer complains dotnet-sdk-5.0.100-preview.6.20266.3-linux-musl-arm64.tar.gz doesn't exist. Attempting from dotnet/sdk complains that dotnet-sdk-5.0.100-preview.7.20356.2-linux-musl-arm64.tar.gz doesn't exist.
Also, how is it that dotnet/installer doesn't have a tag for preview 7 and doesn't seem to have any updates for it? Has the installer build...
It would be great if we can get an update on what c# 9 features are included in every preview, as I understand it, some of the immutable stuff is in this preview?
Will Office VSTO be updated to .NET 5?
I’m trying to keep up with these releases of .net framework 5. But I’m having trouble understanding these preview versions in relation to the multiplatform UI. After all, will it be UWP, blazor, WPF, MAUI? Could someone explain to me or point me somewhere where I can get this information. I would love to know what will happen with WPF in versions 5 and 6 of the net framework.
Hi, wondering when there will be support for gRPC in .Net 5? Specifically for use in Blazor WebAssembly apps. Thanks and keep up the good work.
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...
.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.
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.
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...
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...
Yep. UWP would actually be a good alternative to the poor future of AOT in .NET/Win32 except of two reasons:
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...
Can’t agree more.
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...