Introducing .NET 5



Today, we’re announcing that the next release after .NET Core 3.0 will be .NET 5. This will be the next big release in the .NET family.

There will be just one .NET going forward, and you will be able to use it to target Windows, Linux, macOS, iOS, Android, tvOS, watchOS and WebAssembly and more.

We will introduce new .NET APIs, runtime capabilities and language features as part of .NET 5.

From the inception of the .NET Core project, we’ve added around fifty thousand .NET Framework APIs to the platform. .NET Core 3.0 closes much of the remaining capability gap with .NET Framework 4.8, enabling Windows Forms, WPF and Entity Framework 6. .NET 5 builds on this work, taking .NET Core and the best of Mono to create a single platform that you can use for all your modern .NET code.

We intend to release .NET 5 in November 2020, with the first preview available in the first half of 2020. It will be supported with future updates to Visual Studio 2019, Visual Studio for Mac and Visual Studio Code.

Check out .NET Core is the Future of .NET to understand how .NET 5 relates to .NET Framework.

.NET 5 = .NET Core vNext

.NET 5 is the next step forward with .NET Core. The project aims to improve .NET in a few key ways:

  • Produce a single .NET runtime and framework that can be used everywhere and that has uniform runtime behaviors and developer experiences.
  • Expand the capabilities of .NET by taking the best of .NET Core, .NET Framework, Xamarin and Mono.
  • Build that product out of a single code-base that developers (Microsoft and the community) can work on and expand together and that improves all scenarios.

This new project and direction are a game-changer for .NET. With .NET 5, your code and project files will look and feel the same no matter which type of app you’re building. You’ll have access to the same runtime, API and language capabilities with each app. This includes new performance improvements that get committed to corefx, practically daily.

Everything you love about .NET Core will continue to exist:

  • Open source and community-oriented on GitHub.
  • Cross-platform implementation.
  • Support for leveraging platform-specific capabilities, such as Windows Forms and WPF on Windows and the native bindings to each native platform from Xamarin.
  • High performance.
  • Side-by-side installation.
  • Small project files (SDK-style).
  • Capable command-line interface (CLI).
  • Visual Studio, Visual Studio for Mac, and Visual Studio Code integration.

Here’s what will be new:

  • You will have more choice on runtime experiences (more on that below).
  • Java interoperability will be available on all platforms.
  • Objective-C and Swift interoperability will be supported on multiple operating systems.
  • CoreFX will be extended to support static compilation of .NET (ahead-of-time – AOT), smaller footprints and support for more operating systems.

We will ship .NET Core 3.0 this September, .NET 5 in November 2020, and then we intend to ship a major version of .NET once a year, every November:

We’re skipping the version 4 because it would confuse users that are familiar with the .NET Framework, which has been using the 4.x series for a long time. Additionally, we wanted to clearly communicate that .NET 5 is the future for the .NET platform.

We are also taking the opportunity to simplify naming. We thought that if there is only one .NET going forward, we don’t need a clarifying term like “Core”. The shorter name is a simplification and also communicates that .NET 5 has uniform capabilities and behaviors. Feel free to continue to use the “.NET Core” name if you prefer it.

Runtime experiences

Mono is the original cross-platform implementation of .NET. It started out as an open-source alternative to .NET Framework and transitioned to targeting mobile devices as iOS and Android devices became popular. Mono is the runtime used as part of Xamarin.

CoreCLR is the runtime used as part of .NET Core. It has been primarily targeted at supporting cloud applications, including the largest services at Microsoft, and now is also being used for Windows desktop, IoT and machine learning applications.

Taken together, the .NET Core and Mono runtimes have a lot of similarities (they are both .NET runtimes after all) but also valuable unique capabilities. It makes sense to make it possible to pick the runtime experience you want. We’re in the process of making CoreCLR and Mono drop-in replacements for one another. We will make it as simple as a build switch to choose between the different runtime options.

The following sections describe the primary pivots we are planning for .NET 5. They provide a clear view on how we plan to evolve the two runtimes individually, and also together.

High throughput and high productivity

From the very beginning, .NET has relied on a just-in-time compiler (JIT) to translate Intermediate Language (IL) code to optimized machine code. Since that time, we’ve built an industry-leading JIT-based managed runtime that is capable of very high throughput and also enabled developer experiences that make programming fast and easy.

JITs are well suited for long-running cloud and client scenarios. They are able to generate code that targets a specific machine configuration, including specific CPU instructions. A JIT can also re-generate methods at runtime, a technique used to JIT quickly while still having the option to produce a highly-tuned version of the code if this becomes a frequently used method.

Our efforts to make ASP.NET Core run faster on the TechEmpower benchmarks is a good example of the power of JIT and our investments in CoreCLR. Our efforts to harden .NET Core for containers also demonstrates the runtime’s ability to dynamically adapt to constrained environments.

Developer tools are another good example where JIT shines, such as with the dotnet watch tool or edit and continue. Tools often require compiling and loading code multiple times in a single process without restarting and need to do it very quickly.

Developers using .NET Core or .NET Framework have primarily relied on JIT. As a result, this experience should seem familiar.

The default experience for most .NET 5 workloads will be using the JIT-based CoreCLR runtime. The two notable exceptions are iOS and client-side Blazor (web assembly) since both require ahead-of-time (AOT) native compilation.

Fast startup, low footprint, and lower memory usage

The Mono Project has spent much of its effort focused on mobile and gaming consoles. A key capability and outcome of that project is an AOT compiler for .NET, based on the industry-leading LLVM compiler project. The Mono AOT compiler enables .NET code to be built into a single native code executable that can run on a machine, much like C++ code. AOT-compiled apps can run efficiently in small places, and trades throughput for startup if needed.

The Blazor project is already using the Mono AOT. It will be one of the first projects to transition to .NET 5. We are using it as one of the scenarios to prove out this plan.

There are two types of AOT solutions:

  • solutions that require 100% AOT compilation.
  • solutions where most code is AOT-compiled but where a JIT or interpreter is available and used for code patterns that are not friendly to AOT (like generics).

The Mono AOT supports both cases. The first type of AOT is required by Apple for iOS and some game consoles, typically for security reasons. The second is the preferred choice since it offers the benefits of AOT without any of its drawbacks.

.NET Native is the AOT compiler we use for Windows UWP applications and is an example of the first type of AOT listed above. With that particular implementation, we limited the .NET APIs and capabilities that you can use. We learned from that experience that AOT solutions need to cover the full spectrum of .NET APIs and patterns.

AOT compilation will remain required for iOS, web assembly and some game consoles. We will make AOT compilation an option for applications that are more appliance-like, that require fast startup and/or low footprint.

Fundamentals and overlapping experiences

It is critical that we continue to move forward as an overall platform with startup, throughput, memory use, reliability, and diagnostics. At the same time, it also makes sense to focus our efforts. We’ll invest more in throughput and reliability in CoreCLR while we invest more in startup and size reduction with the Mono AOT compiler. We think that these are good pairings. Throughput and reliability go together as do startup and size reduction.

While there are some characteristics where it makes sense to make different investments, there are others that do not.

Diagnostics capabilities need to be the same across .NET 5, for both functional and performance diagnostics. It is also important to support the same chips and operating systems (with the exception of iOS and web assembly).

We will continue to optimize .NET 5 for each workload and scenario, for whatever makes sense. There will be even greater emphasis on optimizations, particular where multiple workloads have overlapping needs.

All .NET 5 applications will use the CoreFX framework. We will ensure that CoreFX works well in the places it is not used today, which is primarily the Xamarin and client-side Blazor workloads.
All .NET 5 applications will be buildable with the .NET CLI, ensuring that you have common command-line tooling across projects.

C# will move forward in lock-step with .NET 5. Developers writing .NET 5 apps will have access to the latest C# version and features.

The birth of the project

We met as a technical team in December 2018 in Boston to kick off this project. Design leaders from .NET teams (Mono/Xamarin and .NET Core) and also from Unity presented on various technical capabilities and architectural direction.

We are now moving forward on this project as a single team with one set of deliverables. Since December, we have made a lot of progress on a few projects:

  • Defined a minimal layer that defines the runtime <-> managed code layer, with the goal making >99% of CoreFX common code.
  • MonoVM can now use CoreFX and its class libraries.
  • Run all CoreFX tests on MonoVM using the CoreFX implementation.
  • Run ASP.NET Core 3.0 apps with MonoVM.
  • Run MonoDevelop and then Visual Studio for Mac on CoreCLR.

Moving to a single .NET implementation raises important questions. What will the target framework be? Will NuGet package compatibility rules be the same? Which workloads should be supported out-of-the-box by the .NET 5 SDK? How does writing code for a specific architecture work? Do we still need .NET Standard? We are working through these issues now and will soon be sharing design docs for you to read and give feedback on.


The .NET 5 project is an important and exciting new direction for .NET. You will see .NET become simpler but also have broader and more expansive capability and utility. All new development and feature capabilities will be part of .NET 5, including new C# versions.

We see a bright future ahead in which you can use the same .NET APIs and languages to target a broad range of application types, operating systems, and chip architectures. It will be easy to make changes to your build configuration to build your applications differently, in Visual Studio, Visual Studio for Mac, Visual Studio Code, Azure DevOps or at the command line.

See: .NET 5 on Hacker News

Richard Lander

Program Manager, .NET Team

Follow Richard   

LOST _ 2019-05-06 09:37:36
Any details of what Java interop will look like? Is it two-way?
Onur Gümüş 2019-05-06 09:48:05
Please proper AOT support for F# this time. 
emiliano84 2019-05-06 09:53:48
And still not a real xaml standard cross platform (xamarin and uwp at least) 
Hitesh Davey 2019-05-06 10:27:40
Well written and greatly explained. Keep up the good work & continue!
Tony Henrique 2019-05-06 10:35:16
Great news! I got curious about the AOT, F#, and Generics and WebAssembly possibilities. Also would be great to hear news about Universal / Cross-platform XAML that runs on Web, Mobile, Desktop and IoT.
Michal Malecki
Michal Malecki 2019-05-06 10:43:42
Great news! How will com interop look like in this brave new world?
Robert Jackson 2019-05-06 10:44:21
Hi Richard, Do you have any details on .net Framework 4.x EOL? We are heavily invested in WF which I know isn't in .net core. We have been looking for a migration plan and would rather not be rushed. 
Charles Roddie 2019-05-06 10:54:22
> Expand the capabilities of .NET by taking the best of .NET Core, .NET Framework, Xamarin and Mono. Wow this is great news! Mono has the breadth of support (iOS, Android, webassembly) but .Net Core has the robustness and performance. So having the best of both worlds is excellent. Of course this is a natural step, but one that takes a lot of effort, so I'm grateful that Microsoft is making it. > We’ll invest more in throughput and reliability in CoreCLR while we invest more in startup and size reduction with the Mono AOT compiler. My experience of the various AOTs is that .Net Native/CoreRT is a higher quality AOT framework, so I would think it would be easier to add an interpreter to .Net Native/CoreRT (which is ongoing work) than make Mono AOT robust and efficient.For example says Mono AOT has 300ms startup time compared with 50ms for CoreRT: a noticeable chunk of slowness for Xamarin apps. > The second is the preferred choice since it offers the benefits of AOT without any of its drawbacks. Makes sense to have this as default. But disallowing slow things like reflection is good hygiene in consumer-facing apps, so it's good to have a compiler option which enforces that.
Mason McGlothlin 2019-05-06 11:02:08
What will happen to Web Forms, given that it's a part of .NET Framework but not .NET Core? I'll personally be very happy if you kill it off. Nevermind, I saw Rich's tweet that Web Forms will remain .NET Framework 4.8 only.
Tobias Käs 2019-05-06 11:02:30
Does this mean we'll finally get .NET Core for x86 on Linux? I'm still stuck on Mono because x64 .NET Core builds have unacceptable high memory requirements compared to x86 Mono, it uses around twice as much memory. Jumping from 1GB to 2GB is just not acceptable.
Dominik Jeske 2019-05-06 11:26:31
What about IL Linker in context of .NET 5? It looks to me that this is little abandoned or I'm wrong?
Roger de Laborde 2019-05-06 11:37:43
Will VB.NET be supported in .NET5? (not clear from this post and the support for it in .NET Core is not complete)
Dmitriy Barday 2019-05-06 11:47:00
Any changes in MacOS mandatory usage to build Xamarin iOS?
Sam 2019-05-06 11:57:27
Really glad to hear you guys are finally going to clean up the naming/versioning mess that has existed since .NET Core was created. It's really odd how Microsoft couldn't admit for so many years that this was the inevitable result of .NET Core development- deprecation of .NET Framework and Mono's libraries- when everyone on the outside saw it clear as day. Is this the end of .NET Standard? Now that there will only be a single .NET library?
Chris Martin 2019-05-06 12:15:16
Is .Net standard finished then at version 2.1 with version 2.0 the last version to support .Net Framework. The current recommendation has been to convert libraries to .Net standard with the broardest support for your target platforms. Is this advice changing here?  i assume if you are converting a library that needs to ruin on framwork, still convert to .Net standard. If not, and Windows UI could be on .Net Core WPF/Win Forms/UWP/Console, don't do .Net standard and just do .Net Core 3.0 and then .Net 5.0 in future?
Mario M 2019-05-06 12:25:00
Official cross-platform GUI library when?
Max Mustermueller 2019-05-06 12:40:06
Will the ahead-of-time native compiler also works for WPF / Winforms .NET 5 projects (pretty please let this happen!!) or will this work for console applications only? Regardless of it, thanks .NET team for the wonderful news! This goes straight in the right direction, amazing.
Johnnyxp64 2019-05-06 12:59:26
just this paragraph brought tears of joy into my eyes!!! Finally! (now let's hope we see windows desktop apps becoming truly cross platform) There will be just one .NET going forward, and you will be able to use it to target Windows, Linux, macOS, iOS, Android, tvOS, watchOS and WebAssembly and more.
Maheshkumar Rajarathinavel 2019-05-06 13:16:11
This is a brilliant and bold move. Explained very well and clears the air very much. Good job team. 
Thomas Claudius Huber 2019-05-06 13:27:04
Super exciting news!I can't say how much I appreciate this very clear and fantastic strategy. Thank you! I noticed 2 things:a) "the next release after .NET Core 3.0 will be .NET 5", but the .NET Schedule mentions a 3.1 LTS. Maybe adding a "major" to "the next release" in the blog post is a good fix for this, I don't know :)b) Did you discuss already what we call for example ASP.NET Core when .NET 5 is out? Will it still be "ASP.NET Core", or will it become just "ASP.NET" again?Thank you for all your hard work, Kudos to the whole .NET Team..NET 5 is the direction I wanted to see, and it fills me with great joy to learn how this amazing platform I love to use will evolve in the upcoming years.
anonymous 2019-05-06 13:31:34
This comment has been deleted.
Leonardo Zambonelli
Leonardo Zambonelli 2019-05-06 14:09:15
What about UI? Will.a common technology be present in the future?
Shimmy Weitzhandler 2019-05-06 14:37:10

Nothing interesting. Microsoft fails to include a cross-platform UI solution year after year.

Xamarin.Forms is dropping Windows support, and doesn't target web, aside from being a sloppy and messed up library. The only close solution out there is the Uno Platform, which gets zero recognition from MS. It's not even in the .NET Foundation.

If you find that this matter applies to you too, please vote on this dev community request.

Really disappointed. A good technology without a UI is like a unicorn without a horn. That's what .NET is.

haidong gao 2019-05-06 14:39:49
net5 支持webform winform wpf wf wcf跨平台吗
Sam 2019-05-06 15:46:52
You guys have to do something about WebForms. There are tens of thousands of websites that use WebForms. Most of those are probably in maintenance mode. This isn't like Silverlight where adoption was much more narrow and mostly limited to enterprises. If no upgrade path is made for Web Forms, you'll eventually have huge swaths of the web running on an insecure framework once your extended support for .NET Framework ends. Not to mention all those sites never receiving any of the perf benefits from all the work going into Core. And not only that, it is in Microsoft's financial interest as well. Every single Web Forms site is sitting on a Windows Server that someone pays a license fee for. Once you essentially tell all those website owners they are on an abandoned framework and need to rebuild their sites, many will almost certainly will rebuild the sites in a web framework that doesn't require a Windows license (including ASP.NET Core).
Thomas Mutzl 2019-05-06 16:01:48
What about the Entity Framework in .NET 5? EF 6 and EF Core have differences. Will both versions be supported?
Andrew Witte 2019-05-06 16:18:22
Where does CoreRT play into this as its not mentioned. Is there no change and it will continue to be the CoreCLR AOT backend for non UWP targets? Really hope .NET Native just merges into CoreRT. I never understood making such a unportable yet most beneficial runtime stuck in a nitch enviroment. Much of that work just goes down the drain for most people. AOT seems to be if not more the most relevent target anymore. The JIT has really never had any value to me personally (other than the very rare off-chance I want to edit code while the app is running which I could live without) and for the most part caused more problems than its solves as its slower in almost any angle you look at it and harder to port. If more focus was on AOT initially .NET would be having a lot less issues now is my guess. At this point the JIT vs AOT experiment has shown AOT to be the big winner for most spaces in my mind so glad to see more effort there. Also QUOTE: “Today, we’re announcing that the next release after .NET Core 3.0” This should say .NET Core 3.1 maybe ;)
Jaime Vasquez 2019-05-06 16:58:47
And in .NET Framework 5, will be exists the possibility to develop a Desktop Application "multiplatform" that works in Windows, Linux and Mac?
haidong gao 2019-05-06 17:20:19
Does webform  support cross-platform
Alexander Zaytsev 2019-05-06 17:35:09
The one thing notably missing from the post is any mention of being able to statically AOT compile a web app with this new paradigm. I am sure a lot people would agree that this scenario would be a major help in a lot of very simple applications that are called millions of times. I understand that is probably one of the more difficult use cases, but one that would be awesome to see realised.
matari ganan
matari ganan 2019-05-06 17:58:17
A question that comes to mind is:If I wrote something with 4.7 which may have features not available to Core 3.0 and then .NET 5 rolls out, will what I wrote not work in .NET 5?
Plus 阿星 2019-05-06 18:04:53
.net framework .net core .net standard .net 5 666666666666
Kathleen Dollard 2019-05-06 18:08:40
@Roger de Laborde Yes! VB.NET is being ported to .NET Core, and that makes it ready to take part in .NET 5.  We don't know yet which features will make sense for VB.NET, so stay tuned. "We will focus innovation on the core scenarios and domains where VB is popular." (from
Weijie JIN 2019-05-06 18:22:36
Finally, the naming makes sense! :D
cheong00 2019-05-06 18:45:55
Btw, IMO the feature I very much want to see is the ability to safely de-interning strings, or perhep even be able to GC the string interning table. That would remove my need to write appdomain unload code just to keep my long running application that process "long non-repetitive string content" running.
Traktor Toni
Traktor Toni 2019-05-06 19:32:42
I really hope you guys focus on making single static binary builds as the default. There is a huge difference in comfort and ease of use when using Golang which produces a binary on every build and it just works and you can take it anywhere immediately. Contrast that to the file and folder dump I'm getting after each .NET build, it doesn't look good at all. It doesn't feel good. It always has weird issues with *something* and making it somehow not portable.
bat forest 2019-05-06 21:18:30
How do you think CoreRT?Will you cancel the project,or make monoAOT become a shell of it,or use monoAOT as a temporarily replace of corert?
Shiyu Tang 2019-05-06 22:33:12
What about WebForms? We have tons of code here.
zhifeng hu 2019-05-06 22:48:36
No, .net 5 is not enough, You need to increase the version number to  => 2019 Welcome to the .net 2019
Kexy Biscuit 2019-05-06 23:01:34
What's the status of UWP? Will it be a part of .NET 5?
Patrick Smacchia
Patrick Smacchia 2019-05-06 23:27:04
Will Visual Studio vNext run on .NET Core 5? This is important to know for VS extension ISVs like us. If a .NET application relies upon libraries compiled for the .NET Fx 4.x runtime, if the application is recompiled for .NET v5 will such library be loadable and runable in the context of .NET v5?  Nowadays VS is released every 2 years so we can expect VS 2021 in 2021 Q1 or Q2 a bit after .NET v5 release in Nov 2020.
晖 郭 2019-05-07 01:24:31
Is there any plan to support RISC-V target?
Neil Moss
Neil Moss 2019-05-07 01:27:07
Will .NET5 be supported on Windows 7, given the imminent demise of support for Windows 7? Same question for Windows 8, I guess, though with less feeling. Thanks!
Andrew Stephens 2019-05-07 01:28:36
Our small team has been working on a major WPF desktop application (.Net 4.5.2) for a number of years, and so the whole .Net Core/.Net Standard revolution has passed us by, and admittedly I still struggle to understand the concepts. In fact I'm ashamed to say that we're still using VS 2013, but are due to upgrade to VS 2019 very soon. It's good (I think) to see that everything will be consolidated into a single version, which should lessen the confusion, but what are the options for projects like ours? I believe WPF applications can now be ported to .Net Core 3, but can we expect this to get even easier with .Net 5, perhaps ultimately becoming as simple as changing the project's target framework?
Aaron Franke 2019-05-07 02:56:46
Targeting Linux is one thing, but when will we be able to develop with .NET 5 using Linux? There is still no Visual Studio for Linux. MonoDevelop exists but it is incapable of developing for mobile due to Microsoft's constraints over it. Or will Visual Studio Code be improved to allow developing .NET 5 apps for any platform?
Govert van Drimmelen
Govert van Drimmelen 2019-05-07 03:04:28
The initial .NET 5 messaging cannot be more confusing. I want to use some .NET technology to AOT compile c# code into a native .dll that will run on Windows. Currently I can kind of do this with CoreRT and the "NativeCallable" magic, but it seems an unsupported scenario going forward. What will be the .NET 5 approach to making an AOT compiled native .dll for Windows?
Reader Man1
Reader Man1 2019-05-07 03:13:52
very very exiting times we are living in, thanks MS. It will be very nice if you can add Dart Interop-Two-Way support, as this will give us the ease of working on both Xamarin+Flutter. and also it will be better of, if MS makes the new UI-to rule them all on all platforms(OSs), that has the same power and speed of Flutter that runs on the or similar powerfull cross platform graphics api. Thanks again on all you good work.
Harvinder Singh 2019-05-07 04:31:11
What about UWP? We haven't heard much about which version would the UWP target? UWP guidance has been tied with .Net Standard versions. Earlier it was 1.4, last year we could start using 2.0. And .Net Core was implementing .Net Standard. What version of .net standard would .Net Core 3.0 be implementing? What about .Net 5? 
Tom McDerp
Tom McDerp 2019-05-07 04:44:59
Full WCF or go home. Mic dropped. We are a bank not a grinder clone. We use rest where it makes sense and SOAP + a lot of biztalk still. Microsoft has abandoned its customers by ignornig the WCF story that they pushed for so long and hard. Right up our asses.
Tom McDerp
Tom McDerp 2019-05-07 05:01:50
No WCF, no go. Get your heads out of your arses already on it.
Hugo Ferreira
Hugo Ferreira 2019-05-07 06:56:07
My thougths about this: * This is a PR way to end up .NET Framework and by the way Mono. * .NET Framework, .NET Core, Mono, Xamarim, .NET Standard, it's a mess and this is a way to clean up and invest in a single runtime, now with more customer based because .NET Core implements WinForms and EF6 but with a minority guy out of scope (WebForms, etc ...). * For me .NET should be a monolitic runtime that should be the standard implementation that runs in several OS (.NET Core) and on top of that nuget packages for specific things that may depends on other libraries or OS: DataSet (this should never be on the standard), WinForms, etc ... This way would be even possible to have WebForms on .NET 5 This move shows that .NET Standard failed miserably and .NET Core was a wrong move, thought by theoretical guys.
Allan Lindqvist 2019-05-07 07:15:19
SuprisedPikachu.jpg  That. Is. Awesome.
Hugo Ferreira
Hugo Ferreira 2019-05-07 07:17:10
.NET Framework have a deep integration with IIS and takes advantage of it (it's all Windows anyway). .NET Core it's agnostic on WebServer and that's cool and on top of that, was made an implemented specific for integration with IIS (after several delays), on the latest .NET 2.2 (IIS In-Proc), however only one App per AppPool in In-Proc way and there is no intention to improve in future ! It's a joke. .NET Core = .NET Mini framework (not for severious applications)
Laurent Kempé 2019-05-07 07:32:51
Is there a place we can read more about "Java interoperability will be available on all platforms."?
Chris Benard
Chris Benard 2019-05-07 07:46:22
Please support server-side WCF. If you don't, you're marooning entire classes of apps. We do DLL sharing and share the interface and objects on both sides. Doing gRPC with proxies is not an acceptable replacement, especially if you're saving serialized representations of objects on various sides. You already support some client-side, as I understand it. Why would you not support your own WCF that you got massive buy-in from developers. Why would we trust you in the future when you abandon us and just say ".Net Framework is done. Use gRPC or REST. WCF is dead."??? This is absolutely insane. I would love to move to Core, and I do on my personal cross-platform projects, but you have loyal Windows developers who bought into WCF that you pushed for a decade and now you're leaving us out in the cold. What is the point in the client-side support if the server-side can never be updated to support anything new after 4.8?
hatim haidry 2019-05-07 09:26:47
What is the future of C++/CLI in .NET 5?
Jason Nappi 2019-05-07 10:45:35
Richard, its not clear what the implications of this announcement are for those who are starting a path from .NET Framework 4.6+ to .NET Core.  Should we continue using .NET Standard as a way to migrate components that can live in both Framework and Core, or is this suggesting that won't be necessary? That we won't need standard anymore? Is the implication that .NET Framework code will be more compatible with Core on .NET 5.0 or that there will be some other migration paths for Framework to upgrade to 5.0 without going through a core migration? 
Leonardo Carreiro 2019-05-07 11:00:03
Will I be able to write a .NET 5 project that references a .NET Framework 4.5 assembly (even if that makes my .NET 5 project only able to run on Windows)? What about a referente to a .NET Core 3.0 assembly?
Orides Pavaneli 2019-05-07 12:02:07
Is Visual Basic dead into this new worl of .NET 5?
Norman Zhou 2019-05-07 16:16:03
Will that new dotnet ship with the Windows OS like it used to?
gc y 2019-05-07 18:05:35
Why does Microsoft want to maintain two runtimes (CoreCLR and Mono)? Why not to merge the advantages of Mono to CoreCLR? Thus developers need not choose runtime.
Gleb Krasilich 2019-05-07 18:33:19
Great news! One .NET to rule them all! Looking forward to see how .NET 5 can be used in embedding scenarios. It is such a good experiance to use C# as powerful strongly-typed middleware language in one's native app. Mono already has some good looking embedding API. CoreCLR hosting API is worse (especially lack of custom internal calls, one have to do some ILGenerator.EmitCalli routine). Also interested in out of the box zero overhead interop with native libraries for such cases as computer graphics. Some proposed languge features already will make life easier but some attention from the runtimes would be nice. And expanded Objective-C and Swift interop is amazing. Can't wait to write my own small game engine runing across Mac, Linux and Windows, utilizing modern graphics APIs like Metal, DX 12 and Vulkan, written entirely in C# and orginized as uniform .NET 5 library!
K. Karlo
K. Karlo 2019-05-07 22:31:54
We MUST have WCF (nettcp + server + client + duplex/callbacks + SOAP). I see here's a open source project (started by MS?): Will this help us?
TBD TBD 2019-05-07 23:41:07
so, what's the servicing story for .NET 5? when there's a critical security vulnerability in the CLR or BCL, do we need every ISV to upgrade their installs, or is MS going to have a Windows Update patch solution?
Misra, Lingaraja 2019-05-08 01:15:16
Thanks for the detailed insights.  My two questions - 1. What is the migration path from moving .net framework 4.6 (MVC 5 and above) to .net 5.0? There are still a good amount of MVC 5 application exists in enterprise. 2. The lack of Always Encrypted support in SqlClient for .NET Core 3.0 is the biggest enemy to adopt .net core. Any plan to support it on .net 5.0?
Joe Amenta 2019-05-08 05:35:02
Hmm, if .NET 5 is just going to have the CoreFX libraries, then what's the future for Mono's class libraries that have no equivalents in CoreFX?  e.g., documents a serious history of porting server-side WCF libraries to Mono, and it looks like there's been partial success so far. It would be a shame if this meant that two implementations of server-side WCF got demoted to "legacy-only" status on the same day.
Georgy Perevozchikov 2019-05-08 07:11:38
I wonder what about wpf on all platforms? Because now I actively use Net core 2.2 + AvaloniaUI and it works on Linux / Mac OS / Windows. How this component will be develop? Because WPF / Windows Forms on Net Core 3.0 only work for Windows... And I am not understand why? Net core must be FULLY crossplatform in my oppinion. It would be great if Microsoft include avalonia ui in Net core 5 (or Net 5, I'm already confused)...
Shalin Pather 2019-05-08 07:26:15
This sounds like a great leap forward. Will we finally be able to make a cross platform GUI in .NET 5 (or the few versions that follow)?
Jens Samson 2019-05-08 07:28:30
For over 10 years now, we've been developing a WebForms appllication in VB.Net which uses L2S to access the DB.  I guess we just wont the jackpot.   How long do you guys think you'll be able to constantly change your mind before everyone gives up on you ?
Olu 2019-05-08 08:59:59
Please, what happens to UWP really (especially as regards mobile and all the adaptive and responsive UI design features it has and which, IMO, makes it better than WPF too)? Or is mobile now just not in the agenda anymore, even in this coming phase? It's clear that ".NET Framework" is being phased out and .NET Core will be the only thing in that space, but clearly UWP is the most compatible thing with the future as clearly outlined, even though WPF and WinForms are being carried along as a refresh and both would never be OK for mobile. I just want to know why UWP in the mobile space is not talked about. So, isn't it OK to now get back to targeting mobile with UWP?
Vu Truong 2019-05-09 00:50:27
Is .NET 5 a Microsft version of Java ?
Eric Finch 2019-05-09 05:48:44
Please consider renaming .Net 5.  As a developer, when I do an online search for help, there is already no way for me to differentiate between searches for old .Net and .Net Core.  My search results are always cluttered with suggestions for the technology that I do not want.  Now, if you add another technology with the name ".Net" in it, getting help online will be even harder.  If the name were ".NetFuture" or ".NetNow" where ".Net" is smashed together with another word, then, I can at least differentiate from the other technologies when I perform a search.  This is a huge hinderance to the entire developer community.  To make matters even worse, before .Net Core was .Net Core, it was .Net 5.  Does no one remember that?  There must be two years of online articles from around 2016 that will be confusing people.
Davide No 2019-05-09 13:55:38
Please make something for Web Forms, open source it, port it, open the code but dont forget : dont make same thing like VB6.
Rainer Queck 2019-05-10 01:12:56
Is it Correct, that WCF will not be available in .Net 5? If so, what is the suggested alternative?
혜원 황 2019-05-10 03:05:30
Hi, Richard. I'm planning to translate this and post my own blog, can I do this? (I'll leave link of original post) Thanks.
SuperCocoLoco . 2019-05-10 03:17:47
And what about Visual Basic.NET in ASP.NET Core or Blazor. Seems to be that Visual Basic users need to stick forever in .NET Framework and will never get FULL support in .NET Core or .NET 5.
Olu 2019-05-10 05:40:25
I intended the most of the following as predictions. I had to say this so no one thinks I'm sharing fake news :-) Anyone can have suggestions that Microsoft can consider. Things change. The most important thing in this article is this... "With .NET 5, your code and project files will look and feel the same no matter which type of app you’re building. You’ll have access to the same runtime, API and language capabilities with each app." And what that seriously implies is that everyone should stop choosing sides. UWP, Xamarin.Forms, WPF and Windows Forms are all going to seize to exist as soon as .NET 5 comes on board. We would have the best of all the 4 in .NET 5. And we would definitely have a new kind of Windows OS since .NET Framework too will be discarded. Sounds like this would be satisfying for everyone within and outside of Microsoft. It's great to see everything now moving towards convergence. People are [maybe] already talking about one Windows, and it's obvious .NET 5 would make that happen. And it is evident as WinUI and Fluent Design are now being isolated from every other platforms. The next big thing after WinUI and Fluent Design would be the backing "backend" platform, which I feel would be more like UWP but that would incorporate all of the things people like in WPF, Xamarin.Forms and Windows Forms. Also, I am sure Windows is gonna be back to mobile devices when .NET 5 arrives. Windows Server too will also have to be converged into the one Windows because it is obviously another obstacle to this .NET 5 thing. So, for now, it's safe to choose any platform to develop with. .NET Core is just a warmup for what's coming. I choose UWP anyway. I can't go back to the archaicness of WPF and Windows Forms. I hadn't been an active UWP developer, even though I had been learning it all along (while instead doing Web development) because Microsoft refused, for a long time, to make an affordable Windows tablet. Now, thankfully, we have the Surface Go. I have one more thing to say... If .NET 5 is going to succeed, Microsoft should be readying affordable Windows devices (especially tablets and phones). That is key in why iOS and Android make sense and are widely adopted. Now, everybody is happy I guess. Btw, please, increase the height of this comment box. It's too narrow. Also, paragraphing does not work well, especially after you edit, i.e. it does not show line spacing. Please, fix it.
Avatar 2019-05-10 07:48:09
.NET 5 is the successor to .NET Core 3, not .NET 4 because calling it .NET Core 4 would be confusing to users. Got it.
Luka Radunovic 2019-05-10 11:12:20
Moving target. I am glad I am still on Web Forms and .NET Framework 3.x/4.x for time being.
Justin W. McCarthy
Justin W. McCarthy 2019-05-10 20:49:14
Thank you for the update! This is great news. The software developer platform side of MS is top notch and improves all the time from front to back of the ops stack. We appreciate all your hard work. I look forward to convergence and out of the box cross-platform development.
波比 2019-05-12 01:37:36
收藏 赶紧入手.NET Core
Bipin Paul 2019-05-12 22:27:01
so  ASP.NET Core will be just ASP.NET 5? (beta versions of ASP.NET Core was also called ASP.NET 5 )
Mazhar Khan 2019-05-12 22:47:24
Alex Sarafian 2019-05-13 05:38:18
Hi, It is good that .net is converging again to one sdk but regardless of the names the reality is that some features are not cross platform, one of them being the system.servicemodel assembly that powers WCF. This was never ported to the core which effectively makes soap unavailable in .net core and powershell core as well. It seems as Microsoft has removed WCF and SOAP from any future plans. Please share if possible, the team's plans about this topic because it is never mentioned and many established technologies and API are still driven by SOAP and some products use advanced versions of the technology. I would like to know if the set of apis will be  cross platform and available in powershell core which depends on .net core Thank you.
Marc Moreau
Marc Moreau 2019-05-13 09:04:36
ASP Web Forms and ASP MVC are two ways of implementing the same thing. So if there is only one way left, that's Ok. But concerning desktop applications, why not merge WPF and Xamarin together in .NET Core 3 and make developpers be abble to work with portable XAML UIs ? Today when you want to make desktop UIs, you have 4 ways to do it : winforms, WPF, UWP and Xamarin. It shoud be better to optimize Microsoft Desktop Application Development into 1 or 2 ways which should be portable on all devices : Android, Apple, Linux as well as Windows. .NET Core should make .NET less dependant from Windows, so that if Windows dies, .NET Framework and C# would have a chance to survive. In another hand, WCF was a smart way to implement Web Services and Interop between Java and .NET. Keep that interop simple please !
Robert Boissy 2019-05-13 09:24:36
MSFT lost valuable time, mind share, and market share by failing to grasp the significance of open-source software early enough. There is another open-source revolution taking place thanks to the maturation of the open-source RISC-V (pronounced "RISC-Five") ISA. MSFT should join the RISC-V Foundation, provide funding to MSR and external academics in this area, and gain expertise and contribute to this second open-source revolution. The RISC-V ISA is especially important to the IoT (extremely low-power sensors) and secure computing (e.g., see "Morpheus: A Vulnerability-Tolerant Secure Architecture Based on Ensembles of Moving Target Defenses with Churn" on the ACM Digital Library). The RISC-V ISA is also of great importance to DARPA and the rest of the DoD, so MSFT's involvement in this space is relevant to the JEDI contract. Amazon's FreeRTOS already supports RISC-V, and Amazon is a significant MSFT competitor-frenemy (and JEDI contract finalist). A roadmap for Linux RISC-V support by .NET would be most welcome.
Michael Taylor 2019-05-13 10:58:34
So basically this is .NET Framework 2020. Everybody saw this coming years ago with .NET Core. All you have really done is replatformed NF to a newer CLR and dropped some tech you don't want to support. In 2021 we'll be running into the same issues that NF has today, just on a newer platform. Changes made to .NET will have to be thoroughly tested across multiple platforms, the fast iteration times that Core was bragging about will be gone because now everybody has to update their platforms together. My app will have to target .NET vX but won't run on all platforms until that platform updates their CLR. .NET Standard, which was supposed to normalize access, hasn't done anything and updating Standard to support all the new stuff will be too much work. So basically .NET is doing what Java did years ago which was virtualize the hardware and require every platform to support it. Just go ahead and tell everybody what we already know - Standard didn't accomplish what we had hoped, it is being phased out. All apps will target Core and "just work". We're back in the same boat with Core that we have now. Nothing has really changed. In 2040 we'll probably be having this same discussion again. Core was nothing but a glorified rewrite of the CLR.
Yordan . 2019-05-14 07:26:09
I so hope for Microsoft to abandone Windows 10 UI for the good of all human kind..
Patrick Smacchia
Patrick Smacchia 2019-05-15 23:55:37
Will the .NET 4.x third-party libraries that rely on WPF and/or Winforms will be runnable as-is on .NET 5? I haven't found an answer to this question but this is a key one I guess for everybody that plans a migration. If the answer is yes, if the CLR v5 will be smart enough to run such .NET 4.x bits, this will relieve a lot of headache. Because migrating custom WPF/Winforms code to .NET 5 will be easy, but the real problem will come from migrating third-party libraries we don't have source for.
Ryan Tremblay 2019-05-16 15:10:58
Great news and great article! Some follow up questions: 1. It sounds like the plan is to have a single AOT solution, probably mostly based on Mono AOT, in which case CoreRT and .NET Native will be deprecated (or folded into the single AOT solution). Is that right? 2. Is it a goal to get Unity to eventually deprecate IL2CPP and replace it with the supported .NET AOT solution? 3. I think the article is indicating that Xamarin's platform native bindings will work in both .NET runtimes. Is that right? If so, is it a goal to ensure Xamarin platform native bindings are usable in Unity based apps (and the Unity editor itself)?
Courtney The coder
Courtney The coder . 2019-05-17 08:43:24
Will it support console like mono and no i dont mean via unity i mean being able to write raw c# hit compile and test it with what ever C++ cross compatiable libarys im useing like SD2. or will this still be playing catch up to mono.Java interop has always been avable using the Java C++ bridge. i feel this is encouraging lazy programming instead of actual improvements.No mention of extension method improvements. such as extension propertys or static class extensions. would be nice to havepublic extension property string WidthCM(this Texture tex){get; set;}Seems ill have to wait for improvements that actually matter for another year.
Gregg Swanson 2019-05-17 09:29:38
Do you plan to support .net remoting?