![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 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
JsonConstructorand 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.
What is the plan for Windows.Devices in .NET5. I have not been able to find information on this value namespace’s future. There is support for GPIO, ADC, PWM and other devices within this namespace. It would be valuable to support this across platforms.
What about the plan of Xamarin in .Net5 ?
Will ASP.NET (now “classic”) that target .Net Framework 4.x will works with .NET 5???
The short answer is no.
Microsoft has said from the very first .net 5 announcement that .net 5 is the current .net core rebranded to .net 5 as a clear sign to developers that it is the next .net and the one to be using moving forward. So Microsoft is skipping .net core 4.x and rebranding to .net 5 to show everyone it is the next major release of .net.
The existing .net framework is for legacy code bases that are not supported in the current .net core technologies and Microsoft said they plan to do maintenance releases for existing .net framework...
Really looking forward to the new version. If I have a bit of feedback around the new
dotnet newtemplates (specifically for F#) where’s the best place to go?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
I’m dying to find out if .NET 5 will have WPF support out of the box on ARM64
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.
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...
Checkout something called Avalonia. It has what you want. If you don’t like that GTK#, if not that Eto.Forms
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.
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
.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.
Why to maintain two CLR? Why not combine them to one?
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.
Will file stream for SQL server be available in asp.net core in .net 5???
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 :
What is the status/plan on the Java layer?
Just wondering, any updates on the Java interop? Also, will it be able to target desktop VMs?