Announcing .NET 5 Preview 1
At the end of last year, we shipped .NET Core 3.0 and 3.1. These versions added the desktop app models Windows Forms (WinForms) and WPF, ASP.NET Blazor for building single page applications and gRPC for cross-platform, contract-based messaging. We also added templates for building services, rich generation of client code for talking to gRPC, REST API services, and a lot more. We’re excited to see that .NET Core 3 has become the fastest adopted version of .NET ever and we’ve gained another million more users in just the last year.
We also communicated with these releases that this would conclude the porting of the app models from .NET Framework. With .NET Core 3, we have ported all of the most used app models as well as introduced newer cross- platform frameworks to replace the ones we did not port.
As we look forward to the next major release, .NET 5, we will continue to unify .NET into a single platform by including our .NET mobile device app model (Xamarin) in .NET 5. .NET 5 will include ASP.NET Core, Entity Framework Core, WinForms, WPF, Xamarin and ML.NET. For the first time, the entire platform will use a unified BCL (Base Class Libraries) for all the app models. Having a version 5 that is higher than both .NET Core and .NET Framework also makes it clear that .NET 5 is the future of .NET, which is a single unified platform for building any type of application.
We have said this many times, but we will reiterate again; .NET Core and then .NET 5 is the .NET you should build all your NEW applications with. .NET Framework will remain supported as long as Windows itself is supported. We will continue to provide security and bug fixes and keep the networking and crypto API’s up to date. It will remain safe and supported to keep your older applications on .NET Framework.
Install .NET 5.0 Preview 1
Today we are releasing the first preview of .NET 5, which is scheduled to GA (General Availability) later this year in November.
See ASP.NET Core updates in .NET 5 Preview 1 to learn about today’s ASP.NET Core release.
Preview 1 includes support for Windows ARM64 for the first time. Today’s release includes the .NET Core runtime. We expect Preview 2 to include the SDK (ASP.NET Core but not WPF or Windows Forms). A later preview will include WPF and Windows Forms. Support for Windows ARM64 will also be back-ported to .NET Core 3.1. We will share more information on that with the Preview 2 post.
Updating existing projects
You can update existing projects by updating your target framework, as follows:
High-level goals for .NET 5
Let me highlight some of the high-level goals for .NET 5:
- Unified .NET SDK experience:
- Single BCL (Base Class Library) across all .NET 5 applications. Today Xamarin applications use the Mono BCL but will move to use the.NET Core BCL, improving compatibility across our application models.
- Mobile development (Xamarin) is integrated into .NET 5. This means the .NET SDK will support mobile. For example, you can use “dotnet new XamarinForms” to create a mobile application.
- Native Applications supporting multiple platforms: Single Device project that supports an application that can work across multiple devices for example Window Desktop, Microsoft Duo (Android), and iOS using the native controls supported on those platforms.
- Web Applications supporting multiple platforms: Single Blazor project that supports an application that can work in browsers, on mobile devices and as a native desktop application (Windows 10x for example)
- Cloud Native Applications: High performance, single file (.exe) <50MB microservices and support for building multiple project (API, web front ends, containers) both locally and in the cloud.
- Continuous Improvements, such as: faster algorithms in the BCL, better support for containers in the runtime, support for HTTP3.
Today’s first preview does not contain all the work to support these high-level goals yet, but we will continue to announce more capabilities and features in future previews.
Improvements in Preview 1
The following improvements are in Preview 1:
Regular expression performance improvements
We’ve invested in significant improvements to the Regex engine. On many of the expressions we’ve tried, these improvements routinely result in throughput improvements of 3-6x, and in some cases, much more. We have a blog post coming shortly that will describe these improvements in much more detail.
Code quality improvements in RyuJIT
Every release includes a set of performance improvements to the code that the JIT generates. We refer to these type of improvements as “CQ” or code quality. In most cases, these improvements also apply to the code generated for ready-to-run images.
The following improvements are in preview 1:
- Improvements for null check folding – Remove the need to generate null checks in more cases by observing more patterns where null checks are provably unnecessary.
- Tuned common subexpression evaluation (CSE) – The JIT looks for and collapses duplicate expressions that only need to be evaluated once (wiki).
- Optimizing “constant_string”.Length – Optimizing this pattern and collapsing the code down to the correct integer value.
- JIT: build basic block pred lists before morph – Re-order phases in the JIT to allow key optimizations to be used earlier, resulting in better code quality and less work for the following phases, which increases JIT throughput (“TP” in the referenced PR).
Assembly load diagnostics added to event pipe
We have added assembly load information to event pipe. This improvement is the start of making similar diagnostics functionality available as is part of .NET Framework with the Fusion Log Viewer. You can now use dotnet-trace to collect this information, using the following command:
dotnet-trace collect --providers Microsoft-Windows-DotNETRuntime:4:4 --process-id [process ID]
The workflow is described in Trace Assembly Loading with Event Pipe. You can see assembly loading information for a simple test app.
Event pipe profiler APIs
Event pipe is a new subsystem and API that we added in .NET Core 2.2 to make it possible to perform performance and other diagnostic investigations on any operating system. In .NET 5.0, the event pipe has been extended to enable profilers to write event pipe events. This scenario is critical for instrumenting profilers that previously relied on ETW to monitor application behavior and performance.
GitHub repo consolidation
As part of the .NET 5 release, we reduced the number of GitHub repos we use to build and package .NET. Repo boundaries have a significant impact on many aspects of a project, including builds and issue management. With .NET Core 1.0, we had over 100 repos across ASP.NET, EF and .NET Core. With this latest release, we can now count the primary repos on one hand. We also moved nearly all repos to the dotnet org.
Check out the new, consolidated, repos:
- dotnet/runtime (was dotnet/corefx, dotnet/coreclr, and dotnet/core-setup)
- dotnet/aspnetcore (was several repos in the aspnet org)
- dotnet/sdk (was dotnet/sdk, dotnet/cli)
We hope that you are excited about the work that is happening with .NET 5! The best way to prepare for .NET 5 is to move all of our .NET Core applications to 3.1- we will make the transition from .NET Core 3.1 to .NET 5 as painless as possible. And if you are still building applications on .NET Framework, please feel safe leaving those applications on .NET Framework but think of using .NET Core 3.1 for all your new applications. There are lots of exciting things coming to .NET!
Great stuff – going to be so great with ONE version of .NET going forward.
However, naming TFM for .NET 5.0 netcoreapp5.0 and not just netapp5.0 is confusing.
It is going to be
net5.0with variations for platform bindings (https://github.com/dotnet/designs/pull/92). The support for
net5.0TFM has already landed in code that is going to be in Preview 3, possibly back-ported to Preview 2.
Thanks Filip, that looks good 😉
this comment has been deleted.
There exist Docker images for .NET 5 preview 1 ?
Yup. Regular location: https://hub.docker.com/_/microsoft-dotnet-core
This is great news team!
Can you provide any progress made or when we will start to see the Java interoperability features for .NET 5? Thx
No news on that yet. We had to scope that out of the .NET 5.0 release in order to build everything else. Would appreciate knowing more about your scenarios. Feel free to contact me (rlander@ms).
bummer. I was hoping for some sort of IKVM replacement. But maybe I was misunderstanding “java interoperability” in the first place.
What is your full email address? Message to email@example.com couldn’t be delivered.
@Tomas – spell out what
Do you mean it’s not gonna be delivered in .NET 5.0 at all?
The main scenario that our team is missing is the ability to use the well developed NLP libraries like OpenNLP, Stanford CoreNLP, MALLET and many more.
Please don’t tell me that you have decided to eliminate it altogether. It was mentioned as one of the major features in your early announcements. 🙁
Same here, that is al we were looking for, java interop. Bummer if its not going to be in 5 at all.
what about promised AOT compilation?
when will i finally be able to drop GO?
my team refuses to use dotnet until it has proper native compilation (single statically compiled executable)
We’ll have more to share in later previews on this. We’re still working on it.
awesome, keep up the great work! can’t wait for that feature to finally come, it’ll be game changer!
Indeed, this is my most wanted feature since it was announced and after they said earlier they got a working AOT Winforms prototype I REALLY hope it will support WPF as well.
Wait and see… Hope to realize AOT compilation as soon as possible, reflect the advantages of dotnet, don’t let us down.
it’ll be game changer!
If C# just compiled to LLVM instead of IL it would be native, run faster and be far more portable than it is now. So much re-invention of the wheel with all these JITs that lead to poor results for what most people need. C# is a great lang besides this major mistake imo.
exactly, they are wasting too much time.. my team adopted GO the next year dotnet core was announced, it was impossible to create a small EXE, you were forced to ship 200 files, and the total filesize was way too huge, that is crazy.. it’s sad because C# is a nice language, but it’s nice that they finally acknowledge it and are working on fixing that mess, hopefully dotnet 5.0 will deliver
That’s not a bad idea, but just as a reminder, MSIL predates LLVM, so if someone reinvented the wheel, that’s not Microsoft.
About .net Framework, this “We will continue to provide security and bug fixes and keep the networking and crypto API’s up to date.” is what we wanted to hear, since was one of the biggest concern. Thanks.
I can’t iterate enough times that we are NOT stopping support for .NET Framework, we just blogged today about an update to it. Our advice is to leave your older apps where they are and thinking of .NET Core 3.1 (and .NET 5 in the future) for new apps.
Really Scott? That’s awesome. I’ve got to tell you Microsoft’s ongoing support of Silverlight has been AMAZING.
Oh, oh, and the recent addition of .NetStandard 2.1 support to .NET Framework 4.8, TRULY TRULY AMAZING.
Please explain to us how .NetStandard even makes sense as a compilation target anymore, when Microsoft…
WILL NOT EVEN ADD NETSTANDARD 2.1 SUPPORT TO FULL FRAMEWORK AND THROW A NOTIMPLEMENTED EXCEPTION!!!!
Yah, that’s great “support”. For the record, I don’t even care, I’ve wholly adopted Core, but please, stop blowing smoke up people’s ****** about supporting .NET Framework. It’s just pathetic at this point.
Yes, you can “think” about new apps. Since Web Forms isn’t moved forward and there isn’t really a replacement. Blazor isn’t there yet iMHO. You ported Windows Forms and WPF. Yet Web Forms was an impossible task. The truth is, you could have done Web Forms, but, chose not to, in order to push the newer less functional stack.
Well our company is so pissed at MS for dropping new features for .NET Framework .. for dropping .NET Framework. We have huge .NET Framework applications we can’t port to Core and using Core in future projects, just mean that we can’t mix them – can’t even use Standard 2.1+ since it is not compatible with .NET Framework. …. sigh!!! What a mess!!!
Any update on the documentation for native linking or native interoperability? Looking to move beyond Mono’s Embeddinator and CoreRT.
We’ll have more to say in later previews on this.
How is Unity doing its integration?
It is possible that Unity may adopt .NET 5 (or a later version) for their tools stack. I am doubtful they will use it for their apps since they target a larger set of platforms than we do. That is why they have focused on their IL2CPP project. We talk with Unity folks fairly regularly, so we’ll be happy to offer any help they ask for.
How is this working? Is .Net 5 or Xamarin getting the “Blazor Native” rendering stack built in?
The Xamarin and Blazor projects are separate but have significant overlap in capability. Xamarin is targeted at client developers and Blazor at web developers. We care about and enable both.
If I might suggest, MS need to get back to ‘.NET basics’ and re-deliver on the Y2000 promise of .NET. There are signs that MS recognise that all the different app ‘silos’ have diametrically moved the fundamentals apart and that it’s time to bring things back together. None the less, your comment concerns me. Blazor is/was initially supposed to be aimed at client side. I don’t really want to be scratching my head if I want to build a client app – do I build a Xamarin app or a Blazor app – should it be mobile, should it be desktop? Should it be for Windows, Android or iOS? I just want to build an app. If we really need Windows as an OS (i.e. something beyond a window, container or browser), a common UI stack where XAML is a super set of HTML should suffice, and I just extend my code for the situation.
So the fundamental issue is that we need a cross platform UI stack atop .NET 5. I haven’t read anything about .NET 5 that addresses that concern.
I always considering .NET 5 will be a cross-platform framework just like Flutter while it seems it will still separate into WPF/Winform/Xamarin and any other parts.
.NET is about choice. Today, we have a very strong offering to target the individual platforms with no loss in fidelity, i.e. full access to the native APIs. With Xamarin Forms you can already write cross-platform applications with high amounts of code reuse; you can expect that we’ll be extending this model in the future. However, I doubt that we’ll ever provide a cross-platform only solution. Sometimes, you need access to a platform-specific API. My hope is that our tooling never gets in the way of doing that while also making it crystal clear when you do so, so that you’re not accidentally becoming platform dependent.
Aha. Thanks for replying to me. I conjecture .Net 5 will be a cross-platform framework base on the programming language of Blazor for Microsoft has paid much on it. And also, it seems we can use Blazor to code Xamarin in the future for Microsoft published an experimental mobile Blazor binding template before long. I think the Blazor binding template will also available in WPF in the future. Well, all just is a conjecture. All of them are a secret until Microsoft publishes all about it.
Nice one, and well done to the team and the community. When is the support for UWP and WinUI coming?
Also waiting for UWP, CoreWindow and SwapChain support.