Announcing .NET 5.0 Preview 7

Rich Lander [MSFT]

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:

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).

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.


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 site on .NET 5.0 since Preview 1 (50% on 5.0; 50% on 3.1) and it has worked great.


Discussion is closed. Login to edit/delete existing comments.

  • Matthew Hill 0

    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.

  • Leomir Santos 0

    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.

  • Eugene Ivanoff 0

    Will Office VSTO be updated to .NET 5?

  • Pelle Branden 0

    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?

  • Jason S. Clary 0

    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 moved?

    Additionally, the script from the now legacy dotnet/source-build project needs an updated replacement over in dotnet/installer (or wherever things are being done going forward) since there’s a catch-22 in the build process for platforms without an existing SDK. There’s no obvious way to build an SDK without a working SDK, right now.

  • Luigi Zambetti 0

    What about VB.NET? It will be supported again?

  • liu long 0

    AOT is important!
    NETCORE is later than openjdk and lags behind Java.
    Now I’m going to fall behind again to golang. Nice work!

  • Zach Saw 0

    .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 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.

    • Ian Marteens 0

      Lucky you. I’m actually seeing regressions in my code (heavy in maths). It seems they have reached the point of diminishing returns.

Feedback usabilla icon