Announcing .NET 5.0 Preview 2

Rich Lander [MSFT]

Today, we’re releasing .NET 5.0 Preview 2. It contains a set of smaller features and performance improvements. We’re continuing to work on the bigger features that will define the 5.0 release, some of which are starting to show up as initial designs at dotnet/designs. The .NET 5.0 Preview 1 post covers what we are planning on building for .NET 5.0. Please take a look at the post and the designs repository and share any feedback you have. And, of course, please install Preview 2, and test any workloads you can with it.

You can download .NET 5.0 Preview 2, for Windows, macOS, and Linux:

ASP.NET Core and EF Core are also being released today.

You need to use Visual Studio 2019 16.6 to use .NET 5.0. Install the latest version of the C# extension, to use .NET 5.0 with Visual Studio Code. Visual Studio for Mac isn’t yet supported.

Release notes:

Let’s look at some of the improvements in Preview 2.

Code quality improvements in RyuJIT

Every release includes a set of changes that improve the machine code that the JIT generates (we call this “code quality”). Better code quality means better performance. In summary, about half of the following improvements are actual new optimizations and the other half are due to changing the flow of RyuJIT to enable existing optimizations to apply to more code patterns.

If you like this style of improvement or are an ARM64 user, you may be interested in Vectorise BitArray for ARM64, coming soon (already merged, but not in Preview 2). This change demonstrates a lot of focus on ARM64 in .NET 5.0.

Garbage Collector


Please take a moment to try out Preview 2, possibly in a container, a VM. We’d like your feedback on the quality of the release. There is a lot more coming, over the next several months, leading up a November release.

We’re running 50% of the .NET Website traffic on .NET 5.0 as a test case, using Azure load balancing. We’ve been doing that since days after we released Preview 1. You may remember us doing something similar with .NET Core 3.0 and 3.1. By splitting the traffic 50/50, we can ensure that 5.0 gets consistently better with constant performance data available to us. This model keeps us honest, and it’s also a great testing approach. We trust our most important site with ALL of our previews, in production (which we don’t recommend for anyone else). That should make adopting our final release a pretty easy choice for you. The version number is in the footer of .NET website; feel free to check at any time.

Stepping back for a minute, many of you might be interested in how the the folks on the .NET Team at Microsoft are doing. We’re doing well. We have lots of Teams meeting every day to organize and support one another, and are just as active on GitHub as ever. The team is close-knit, and collaborating across multiple time-zones. We’re all focused on this release, and very much intending to deliver what we set out to deliver when we first defined our plans, after releasing .NET Core 3.0. Take care.


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

  • J. Portelli 0

    staysafe #thankyou

    • Jonas 0


      Stay safe, thanks.

  • Tony Henrique 0

    This is awesome!

    I am looking forward to see more news about WebAssembly on .NET 5.
    Waiting for BUILD.

  • Andrew Witte 0

    Is there more info on the “(Pinned Object Heap) feature improvements” without going through a goose chase in lengthy GitHub conversations?
    Any performance tests in C# code?

    I use fixed arrays a lot to interface with C methods. Like in a game loop happening potentially 100’s-1000’s of times a seconds.
    Will these improvements be beneficial in that context?

      • Andrew Witte 0

        The “GC.AllocateArray(…)” method is a great addition.
        Can see this being used a lot in performance critical code.

        Besides this framework addition. Another big use case a lot of people run into C# with is fixed fields with a custom element type or fixed multi-dimensional arrays. Both examples below are not possible in C# today.

        ————————– Custom fixed array element Example:

        struct Rigidbody
        public Vec3 pos, linearVel;
        public Quat rot, angularVel;

        unsafe struct UDP_Packet
        public int rigidbodyCount;
        public fixed Rigidbody rigidbodies[16];

        ————————– Multi-Dimensional Example (OpenVR SDK runs into this issue for example):

        unsafe struct Matrix4x4
        public fixed float m[4][4];

  • Daniel Frank 0

    Any plans to allow Tier 1 quality code for R2R images?

    • Richard LanderMicrosoft employee 0

      Depends what you mean by that. If you are talking about the JIT, there is tier 0 and tier 1. R2R is a pessimized case of tier 1. So, you have that already, it’s just like 90% (or something like that) of tier 1. In this release, we have three new features we’re developing for R2R (version bubbles, composite images, and opt-in to a higher SIMD API than SSE2). All of these help close the gap on R2R for steady-state and are expected to be a big step forward on startup perf. Note that we haven’t performance tested any of it yet, mostly because it doesn’t all quite exist yet. Here are some of our conversations related to this topic:

      • Daniel Frank 0

        Thx for the quick response. Glad to know about that. R2R already has this kind of code quality in 3.1?

        • Richard LanderMicrosoft employee 0

          What I explained about existing R2R is true back to .NET Core 1.0. In fact, before .NET Core 3.0, we used fragile NGEN (same as .NET Framework) for System.Private.Corlib.dll (and only that one assembly). Fragile NGEN is one step better toward jitted code (from a steady-state standpoint). We stopped supporting fragile NGEN in 3.0 because it was too expensive for us. Our plan is to make R2R closer to what fragile NGEN was AND to use it for all framework assemblies, and to enable it as an opt-in scenario for users, too. That’s the “version bubble” feature. More on this still to come.

  • Anand C 0

    Looks like the .NET Core name is continued to being used in the project file(as .netcoreapp5.0) and also in the footer of .NET Website…? will it be named to just .NET 5.0 in the RTM, since that was name chosen without adding suffixes (like framework, core…) when the unification was announced?

  • Leonardo Ferreira 0

    quick question: the “Single Device project” means desktop apps for Mac OSX?

    • Richard LanderMicrosoft employee 0

      I believe the finalized plans on that will be announced at Build. I don’t know the final plan on platform matrix.

  • ext sub 0

    Is there any plan to support bcrypt, scrypt, argon2 in System.Security.Cryptography?

    • Jeremy BartonMicrosoft employee 0

      We rely on system cryptographic libraries for algorithmic primitives. According to there’s still no support in Windows CNG for any of those algorithms, so we don’t want to add them in .NET (where they would just throw PlatformNotSupportedException on Windows… and probably macOS).

  • Gábor Szabó 0

    Hey Richard and Team!

    Hope you are all doing well (considering the circumstances) and enjoy the great work you do on .NET. Keep it up and keep us posted!

    Warm regards,
    The .NET community.

  • Rojan Gharibpour 0

    Is it true that Microsoft has ditched the plan for a Java interpreter in .NET 5.0?
    We are missing the scenario where we need to use the well developed NLP libraries like OpenNLP, Stanford CoreNLP, MALLET and many more in .NET.
    It was mentioned as one of the major features in your early announcements. Please don’t tell me that you have decided to eliminate it altogether. 🙁

  • Tushar Agarwal 0

    Any plans of migrating Enterprise Library to .NET 5. It is used by many projects. We still dont have an official port for .NET Core 2/3


    • Tsahi 0

      EntLib is dead since 2013. You can find a few projects on GitHub of porting it to .NET Core if you like, but they’re not official. I started one myself, but it pretty much halted with the Corona Virus outbreak.

Feedback usabilla icon