Announcing .NET 5.0 Preview 3

Rich Lander [MSFT]

April 23rd, 202022 0

Today, we’re releasing .NET 5.0 Preview 3. It contains a set of new features and performance improvements. We’re continuing to work on the bigger features that will define the 5.0 release. 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 dotnet/designs repository and share any feedback you have. And, of course, please install Preview 3, and test your workloads with it.

You can download .NET 5.0 Preview 3, 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. .NET 5.0 isn’t yet supported with Visual Studio for Mac.

Release notes:

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

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

Vectorise BitArray for ARM64 – dotnet/runtime #33749 — The BitArray class was updated to include a hardware-accelerated implementation for ARM64 using ARM64 intrinisics. The performance improvements for BitArray are very significant. Credit to @Gnbrkm41.
Implement simple version of On Stack Replacement (OSR) – dotnet/runtime #32969. On-stack replacement (OSR) is a new capability that allows the code executed by currently running methods to be changed in the middle of method execution, while those methods are active “on stack”. This feature is currently experimental and opt-in (on x64), and targeted at improving the more challenging performance characteristics of tiered compilation. Please try it out and give us feedback.
Dynamic generic dictionary expansion feature dotnet/runtime #32270 – Some (maybe many) uses of generics now have better performance (initial performance findings), based on improving the implementation of low-level (native code) dictionaries used by the runtime to store information about generic types and methods. See Perf: Collection Count() is Slower in Core than the CLR for more information. Credit to @RealDotNetDave for the bug report.
Implement Vector.Ceiling / Vector.Floor dotnet/runtime #31993 – Implement Vector.Ceiling / Vector.Floor using x64 and ARM64 intrinsics, per API proposal. Credit to @Gnbrkm41.
JIT: allow CORINFO_HELP_READYTORUN_GENERIC_HANDLE to be optimized dotnet/runtime #34221. Improves code quality for generics in Ready2Run images.
JIT: enable tail calls and copy omission for implicit byref structs #33004. Improves code quality for structs as arguments in “tail call” position calls.

System.Text.Json improvements

Add support for preserve references on JSON dotnet/runtime #655 – Enables ReferenceLoopHandling, which is one of the key features of JSON.NET serialization.
Add new System.Net.Http.Json project/namespace dotnet/runtime #33459 – Adds new extension methods for HttpClient that allow serialization from/to JSON.
Add JsonConstructor and support for deserializing with parameterized ctors dotnet/runtime #33444 — Adds support for immutable classes and structs to JsonSerializer.
Add JsonIgnoreCondition & per-property ignore logic #34049 – Adds support for null value handling, which is another feature of JSON.NET serialization.

.NET SDK Support for .NET Framework Assemblies

The .NET SDK will now auto-reference the Microsoft.NETFramework.ReferenceAssemblies NuGet package given a .NET Framework target framework in a project file. This change enables building .NET Framework projects on a machine without the required .NET Framework targeting pack installed. This improvement is specific to targeting packs, and doesn’t account for other dependencies that a project may have.

Closing

Please take a moment to try out Preview 3, 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.

Rich Lander [MSFT] Program Manager, .NET Team

22 comments

Comments are closed. Login to edit/delete your existing comments

Soheil Alizadeh April 23, 2020 11:24 am 0

typo on dotnet/rintime #32969
Chris Bergmeister (MVP) April 23, 2020 1:29 pm 0

Typo in Closing section: It still mentions the previous ‘Preview 2’
Tony Henrique April 23, 2020 9:22 pm 0

.NET 5 will be awesome!
Nick Ac April 24, 2020 1:14 am 0

Just wondering, any updates on the Java interop? Also, will it be able to target desktop VMs?
Rojan Gharibpour April 24, 2020 3:24 am 0

What is the status/plan on the Java layer?
Patrick Deschênes April 24, 2020 4:14 am 0
About Swift interoperability in .NET 5, I was wondering what features are planned for .NET 5.

I am asking the question because this topic got raised on the Swift forum lately and people there didn’t seems to know what
this .NET 5 Swift interoperability meant.

For example :
- Would it use the official Swift implementation or one provided by Microsoft
- Would it work on Windows
- Would we be able to call .NET from Swift
- Would we be able to call Swift from .NET
Kelvin Mwenda April 24, 2020 7:25 am 0

Will file stream for SQL server be available in asp.net core in .net 5???
theuserbl April 25, 2020 1:22 am 0

What happens with Mono after .NET 5?
.NET 5 is the real successor of .net Core.
.NET Framework will be discontinued.
And what is with Mono? Is it then deprecated, too?

In the picture, I have seen on a news side, it seems to be coexisting with .net 5
https://www.heise.de/imgs/18/2/8/7/3/1/6/5/net5-prev2-c8b068c5bf13a1a8.png
- Marina Sundström April 25, 2020 4:46 am 0
  
  .NET 5 is about unifying .NET by sharing implementation and tools.
  
  Microsoft and the community have been working towards making Mono run the same implementation of the Framework Class Library as .NET Core.
  
  In the end, there will be two CLR implementations that share the same Framework Class Library.
  (Core)CLR is for desktop and cloud. Mono Runtime will be the one you use when building embedded and mobile applications with Xamarin.
  - gc y April 27, 2020 6:14 am 0
    
    Why to maintain two CLR? Why not combine them to one?
    - Charles Roddie April 28, 2020 4:48 am 0
      
      Combining them into one is a very large task and not feasible by November this year.
      .Net 5 (CoreCLR+MonoVM both running the same CoreFX) represents a half-way point that took years of work.
      After .Net 5 I am sure they will continue to consolidate mono and coreclr until there is only one runtime.
Malachi Burke April 25, 2020 1:57 pm 0

ARM64 support – very awesome. Does your long term roadmap continue to include ARM64 support? We’re evaluating .NET Core usage for a long-term embedded Linux system
- Hernan Martinez April 26, 2020 6:50 pm 0
  
  I’m dying to find out if .NET 5 will have WPF support out of the box on ARM64
  - Jack Bond April 27, 2020 12:28 pm 0
    
    It won’t. An army of brain dead zombies compose .NET project management.
    
    After all, why could you possibly want a cross platform UI framework which would allow you to create app stores for MacOS and Linux?
    
    The math is really simple. Which would be better? Have your developers
    
    1) Waste millions of hours coding with a moronic framework like Electron?
    2) Remove Windows dependencies from WPF and provide a cross platform UI framework that would benefit EVERYONE?
    
    P.S. If you go with 2, you just might win back a few Silverlight developers who you lied to and completely f****d over.
    P.P.S Option 2 is only THE MOST REQUESTED .NET FEATURE TEN YEARS RUNNING.
    - Tsahi April 30, 2020 10:24 am 0
      
      You are saying “Remove Windows dependencies from WPF” as if that’s a day’s job. WFP is built on top of DirectX, and was designed as a Windows technology. removing the Windows dependency will probably require rewriting half of it.
    - Troy Robinson May 20, 2020 3:22 pm 0
      
      Checkout something called Avalonia. It has what you want. If you don’t like that GTK#, if not that Eto.Forms
  - Austin Harris April 28, 2020 8:39 pm 0
    
    FWIW if anything..
    
    Not quite what your asking for, but I’ve had similar issues with building cross platform UI. In the end I’ve started going down the Blazor WASM route. Not quite WPF, but at least you can do your Front-end work in C# and still be Linux and mac friendly. Browser rending performance is hardware accelerated, you just have to find a way to launch your browser window in a chrome-less mode if your going for that native UI look.
tom light April 26, 2020 12:06 pm 0

Really looking forward to the new version. If I have a bit of feedback around the new dotnet new templates (specifically for F#) where’s the best place to go?