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


Leave a comment

      • Avatar
        John Stewien

        I’d be interested in implementation details, e.g. will .jar files be transpiled to .NET IL (my preference)? or will IL be transpiled to run on the JVM? or will stubs be generated to marshall data between the JVM and the CLR?

      • Avatar
        Rojan Gharibpour

        Hi Richard,

        Can you clarify if this feature is still part of the .NET 5.0 plan?

        It doesn’t seem so from the announcements for the preview 1 and 2.

        This is a very important feature for our team.

        I would highly appreciate a clarification.

        Thanks in advance.

      • Avatar
        Richard Przybylski

        Xamarin.Android?  We have many of us out here using windows phones.  Sorry but I believe we need to continue the windows phone support. Java might work but I don’t believe that moving the direction where we have to have more developers than room available in a building and have found that going that direction, as in SAP, you spend, spend and spend.  Moving the direction where a framework is comepleted and adding small app’s internally is a much simpler and less resource dependent operation.  We need to become less dependent on India to develop our applications and thinning our resources isn’t getting the job done.  If we open our eyes and see the loss of control in business here in our country maybe we can begin to build our resource base away from gaming and into the business where it belongs. 

        • Avatar
          Ronak Sankhala

          Hi Richard

          I am Indian.
          I have Windowa Phone.
          Even i have 2 Windows Phone.
          SINCE 2015.
          I LOVE windows Mobile.

          I Support all The Things You Said.
          Microsoft Should Support Back To Windows 10 Mobiles.
          With More Capabilities than Android.

          Some Features i Suggest.
          Mobile Should Be Like Real Windows that support 3rd Party Softwares..

          Also Support Emulator like Bluestacks.

          Mobiles Support Real 4G or 5G Sim With VoLTE .

          My Vision said Microsoft Mobiles are More Popular than IOS or Android.

          Thanks And Regards
          dotNet Developer.

      • Chris Benard
        Chris Benard

        I don’t understand the purposeful killing of WCF. It seems sadistic. They got us to buy in and make our apps rely on it, and now they’re telling us we can’t use it in the future, when our apps are already deeply tied to it.

        • Avatar
          Alexander Krylkov

          Agree, WCF requires too much time to support/setup and develop rather than HTTP REST API (I am comparing to Simplify.Web).
          If you have a good architecture of your services (like, WCF-lelated layer is not tightly coupled with you business logic), then it is not hard to migrate to any HTTP REST APIs.

          • Avatar

            Well but you are referring to WCF only as a Rest API… and WCF is able to handle TCP, FULL Duplex, HTTP Rest and others… HTTP REST is pretty much only used for web applications, not for fast network communication.
            And we simply don’t have other alternative to WCF regarding to network communications (real-time systems). So basically not having WCF in .NET Core (.NET 5) means all backbone systems (which processes and communicates real time data) are unable to use .NET 5.

          • Avatar
            Vladimir Neverov

            Really? What about distributed transactions, service discovery,routing, service announcements?
            How about ability to switch your underlying communication channel (TCP, Net Pipes, UDP) without rewriting code? What about ordered message delivery, control over service instantiation, service sessions?

    • Avatar
      Charles Roddie

      Xaml is just an optional markup language for some ui platforms. Making it universal didn’t make sense which is why that effort stalled: the underlying UI platforms had different features and classes, so why would a markup language describing them be the same?Xaml really became too much of an obsession in .Net for a while, and extended too far. But not it’s being humiliated by being used as a PR term (“XAML islands”, “Microsoft.UI.Xaml”) for things that have nothing to do with markup.

      • Avatar

        If you had running water to your home that was shut off for obscure reasons, you’d get a little obsessive with making sure it gets turned back on, too. 😁  Saying it’s being humiliated now is a good way of putting it.  There was another announcement @ //build last year for a “performant” Xaml that had nothing to do with markup.  It was pure code which basically circumvented all the elegant visual designer aspects that Xaml was intended to leverage.  I forget its name and it’s not worth the effort to look it up.

        • Avatar
          Charles Roddie

          XAML and associated design tooling is decent and makes sense for design. But the binding approach is massively hacky and can’t be fixed without starting from scratch. Xamarin would have 1/2 the size and 1/2 the bugs if it didn’t include bindings.

          • Avatar
            Dennis Fehr

            Visual Studio 2019 is made with WPF and XAML. It’s not just for Xamarin. 🙂 The editor now supports hot reload for Xamarin forms, but also for making editor extensions.

      • Avatar
        Michael Hoagland

        Echoing the above, but my environment is HEAVILY using WCF. Right now we’re doing all kinds of RPC research to figure out what else can work best for us. The biggest issue is the support for various binding types and the extensibility model.

        • Avatar
          Richard LanderMicrosoft logo

          It will continue to work great! There are so many Microsoft services running on .NET Framework, including HEAVILY using WCF. Microsoft itself is the exact same as your environment in this respect. Many services will stay on .NET Framework for many years. Other teams are adopting .NET Core, as you would guess. Some are adopting ASP.NET Core and others are looking at gRPC. .NET Framework will be there for you and .NET Core will continue to move forward when you decide to get on that train. You’ve got lots of good choices available.

          • Przemysław Wasylko
            Przemysław Wasylko

            Frankly speaking I am annoyed with all that ‘It will continue to work great!’ mantra. No one will rewrite millions dolar worth system to gRPC. Instead of providing easier way to move to .net core by enabling WCF Service Host in .net core we, loyal MS customers who invested heavily in WCF because years ago on another Build conference we heard it is a way to go, we are offered with a dead end.No newer C# version goodies on 4.8. No newer netstardards on .NET 4.8. So next time please rethink ‘it will contnue to work gereat’ statement.Thanks.

          • Tom McDerp
            Tom McDerp

            Look its the Microsoft way to lead developers down painful, expensive dead ends. Why would they want to change this when they can piss off even more customers?  WCF is still huge in corporate environments  and even within Microsoft’s own products and services. But then again these are the guys that thought Windows 8 was a good idea and that a visual studio menu shouting at all caps as default was a win. They have lost their way. Declining build attendance being a good indicator.

          • Avatar

            And announcements for that matter.  Seems like .NET 5 was the only blip on the radar.  That said, I wouldn’t mark .NET as a dead end with all its cross-platform support now.  Also, investments in performance are very tell-tale.  They want users to adopt this and they are — or at the very least, .NET is getting respect outside of MSFT circles.

          • Avatar
            Richard Przybylski

            Agreed! However, .Net is being pushed out.  I love it .Net and use it daily.  I’m a SharePoint developer and that is my livelyhood.  I would love to see us using it to it’s potential rather than thrown away because everyone wants to reinvent the wheel on every project.

          • Przemysław Wasylko
            Przemysław Wasylko

            It would enough to open source basic parts of WCF and make it working on core (let’s say WS-I Basic Profile 1.1). Communuty would do the rest.I know it wouldn’t be 100% drop in replacement due to nature how core http stack is oriented but that would be acceptable.But apparently we are not going to be given even that.

          • Dan Donithan
            Dan Donithan

            Why are you leaving so many comments about WCF? WCF is dying dude. It’s not 2008 anymore. Communications frameworks are evolving, and if “corporate environments” don’t evolve with it, they will die, just like every other enterprise platform that has coupled itself with dead end technologies.

          • junli antolovich
            junli antolovich

            Well, WCF and SOAP may be dead to Microsoft, it is not dead in the enterprises. The standard bodies are still publishing XML standards, which are used to define the communicate contracts for enterprises and governemnt entities. 
            What is the rational for Microsoft deciding to kill it and force us all to look different strategies to filling the void? 

          • Avatar
            Vladimir Neverov

            WCF is not dying and probably will not for a foreseeable future. There is simply no alternative for it in .Net Core. Can you enlist your services in a single transaction ? Not in .Net Core. Is there service discovery, service announcements, routing available out of the box with . Net Core ? How about managing your service instancing : per- call, per-session, single? – not there.
            We are using these features extensively and will continue until there is anything comparable in Net Core.

  • Avatar
    Charles Roddie

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

    • Avatar

      Not porting WebForms is huge mistake that Microsoft and the larger web will regret. It is ensuring that a huge swath of the internet remains stuck on an outdated platform with absolutely no viable upgrade path. One that will eventually become insecure when MS stops issuing patches for .NET Framework.

      • Avatar
        Jon Miller

        @Sam I agree. It is RIDICULOUS that Microsoft ported Windows Forms and WPF to .NET Core but REFUSES to port ASP.NET Web Forms. To this day, ASP.NET Core does not match ASP.NET Web Forms in terms of RAD. IMHO, Microsoft had the design right to begin with. Instead, they chose to dumb it down and copy Ruby On Rails. While there are cool aspects to ASP.NET Core/MVC, the problem has always been a LACK OF UI CONTROLS. Not everyone wants to “program at the bare metal”. I prefer to work at the proper level of abstration as an application developer, not waste my time in JavaScript hell. I am able to do that with Web Forms. Microsoft is already bleeding a lot of developers and losing out to Python. Web Forms developers should remember this and evaluate other platforms. Furthermore, the next version of EF Core will standardize on .NET Standard 2.1 which isn’t supported by .NET Framework, meaning, that you are also stuck on an old version of EF Core from here on out. All the more reason to have given up on EF a long time ago and switch to something like Dapper. EF Core is another example of a Core project never having become a complete replacement for its predecessor. If you aren’t going to port Web Forms, Microsoft, you should open source it.

        • Avatar
          Robert Vanya

          I’m using WebForms since 2007. Every 2-3 years I try to look for something better (inside .NET), but I must say that all new alternatives, from perspective of maturity level do not reach 30% of WebForms. I agree that today its model is outdated, a website markup should not be rendered on server side anymore, but somehow still this is the most efficient and productive way to start to build something, and then to include new features, like including fancy js libs and adding the supporting services/APIs using some new .NET features. I’m also preferring WCF over REST, because from perspective of abstraction is better. Even if its configuration is hard. For me, REST is bound too much to http. Today web and http are trendy, but I’m writing software more than 25 years and I already learned nothing stays forever. From ORM side I also like the best the old good XSD Dataset, these give the most freedom to make an ORM layer. EF is for me a limitation, it degrades the performance a lot, too automatic, no room for tricks and hacks. Today there are 100 ways to do things, but every way is only on a low maturity level, poor tool/designer support, forcing developers into many limitations. In the last 5-8 years this industry is somehow stuck, tries to find its way out of the jungle of millions of possibilities, but can’t show up a real progress, only newer and newer experiments. Until this is not stable, I thinks it’s a bad idea to drop old good working methods, like the WebForms are.

        • Avatar
          Richard Andrews

          Try Blazor webassembly if you can – it has all the good bits of webforms but brought up to a much more scaleable modern paradigm. If we are talking RAD then you can get all the benefits of a react / redux js stack with c# all the way down. Serioisly I have found it to be incredibly rapid to knock out POC stuff whilst its been in development and now its just gone prod support.

      • Avatar
        Brian Thomson

        I agree.
        Every few years, MS tell us “this is the new way forward”, as they did with WCF. Now they drop WCF. In my view no great loss – they took all the complexity that was in code (where is could be debugged) and moved it into config files (I’ve spent many hours fiddling with config). 
        I regularly browse .Net core fora, and find that some basic yet essential feature is coming in the next release.
        There is so much across the Microsoft spectrum that is half-finished or coming soon – Look at Edge – from day 1 it hasnt supported NTLM properly, now its being getting chromium stuffed in, and lo and behold, Edge-dev supports NTLM like IE11, except the HTML5 input types work.
        On desktop, UWP was very clever, supporting every windows platform from Phone to Server. MS Dropped Windows phone, so now its Raspberry Pi to server, both of which often run headless, dont need clever UI. UWP on the PC? Yes, but its slow to write and debug, slow to start – so slow they had to build in a “loading page” to give the appearance of quick run, and of course if you want cross-platfrom, you have xamarin – almost UWP but not.
        If we use Web forms / Win forms, its not because we’re Luddites / sticks-in-the-mud / afraid of new tech. Its because we’re paid to be productive, creating stable, quick, familiar applications which may well get dropped on to 4-10 year old Operating Systems, with restricted amounts of RAM.
        I’ve yet to hear a client say her business users are demanding the “dirty glass” Aero caption bars on the new LOB application. 

        • Andrea Gasperi
          Andrea Gasperi

          I completely agree, the productivity and stability that I can have with WeForms is not comparable with other technologies today.
          I think that considering what happened in these years it would make sense to rethink that decision.
          What they are doing with server-side Blazor is fantastic, but it leaves me – if possible – even more frustrated.

      • Avatar
        Duc Thuan Nguy

        I agree with you. Many people comment about old techs as if we will always write new applications and have choices to use the latest technologies without having to maintain decade-old code bases. I get fed up with “advices” such as “abandon WCF and use X instead” or “so do not upgrade”.

    • Avatar
      Tomáš Herceg

      Porting Web Forms would be very difficult for Microsoft – there is a lot of legacy code and it is too tightly bound to IIS, and honestly, I cannot imagine it without significant breaking changes. 
      However, if you have Web Forms applications, you might want to look at DotVVM. It is an open source framework (a member of the .NET Foundation) that is inspired by Web Forms but it is MVVM. It is easy to learn for any Web Forms developer, and it supports both old ASP.NET and new ASP.NET Core. Thanks to that, it can be used to migrate Web Forms applications to .NET Core. It is not a magic wizard which will do the migration automatically – you still need to rewrite all the pages to DotVVM syntax (it is quite similar, see the comparison page) and extracting the business logic into the viewmodels, but it is still much less work than rewriting the entire application from scratch. The best thing is that you can do the migration page by page and you can add new features in the app at any time. After you get rid of all the Web Forms stuff, you can just switch the project to .NET Core. If you like Web Forms, I am quite sure you will like the MVVM way of doing things in DotVVM.Here is the sample repo showing the process of migration.

      • Avatar
        Brian Thomson

        Not entirely accurate, since around .Net 2 a webform (aspx page) could be hosted in a .Net application. Admittedly it would need work to build a full web server, but webforms don’t intrinsically require IIS.
        As for “significant breaking changes” yeah, look at openid connect – our next big task is to rebuild our authentication scheme.
        And Microsoft.Azure.CosmosDB.Table vs Microsoft.Azure.Cosmos.Table
        System.ComponentModel.DataAnnotations vs System.ComponentModel.Annotations

      • Andrea Gasperi
        Andrea Gasperi

        Well… we are talking about the Microsoft, not the pizza & fichi & co… I think they can manage to do the porting… And also some significant breaking changes are completely acceptable or even desirable.
        The point here is that the programming style used by WebForms is great once understood. And it sounds really a waste for people that is productive and happy with .aspx to abandon it.
        MVC and razor was somehow a step behind. I remember the guys telling me… “look, it’s easy it is almost like it was in asp.classic”. Yes and then your code is a mess (as it was in asp.classic).
        This is also proven by the fact that everyone (included me) is now exited by Blazor. But the question comes straight to me: “Why Blazor server side yes and WebForms server side no?”

  • Avatar
    Tobias Käs

    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.

      • Avatar
        Kharlamov Constantine

        I think this is important with disregard to Tobias’s usecase. GNU/Linux is IOT and mobile — sure you want to target these? Besides, with WSL getting improved nowadays one would expect more and more people finding out about GNU/Linux and trying it out, and hence trying out targeting .net on these platforms as well. Furthermore: there already are 2 big existing ecosystems: GNU/Linux and .NET applications. Sure users of the first may want nice things from the second ecosystem.
        TL;DR: cross-platform should be cross-platform.

    • Avatar
      Aaron Franke

      Are you saying that your app uses twice the memory with 64-bit builds? That’s not normal and the solution really should be to fix 64-bit rather than to improve 32-bit support, as 32-bit is outdated and has been for a decade and it’s on the way out.

      • Avatar

        64-bit pointers are twice longer than 32-bit, so the applications can grow a bit less than twice in memory usage if the application has lots of in-memory data.
        Btw, regarding “it’s on the way out”, not agree with that.
        For most e-commerce applications, the memory usage is not that much – tops 64MB per session should be enough.
        Note that even Visual Studio up to 2017 itself did not offer 64-bit version because of the expected memory usage increment.
        And then if your web application needs 32-bit library to do certain things (say, some pretty well known 2-factor authentication libraries that only exists as 32-bit ISAPI module), if your company is not going to pay for upgrade and replace all the tokens (that costs ALOT), you’re stuck in 32-bit builds. 

    • Avatar
      Kathleen Dollard

      The VB runtime (Microsoft.VisualBasic.dll) will be expanded in Preview 5 (out yesterday) and further expanded in Preview 6. We’re looking at feedback on some parts. For example, audio has low usage and we’ve had feedback that it isn’t a great way to do audio now, so we don’t plan to port that part of the VB runtime.
      VB will move forward with .NET Core. 

      • David Carta
        David Carta

        The question was clearly not about the VB runtime. 
        There is a huge community of VB.NET language developers who want to use the CRL to develop their applications.  
        Xamarin does not allow direct VB.NET coding for everything, nor does Core, AFAIK – when will Microsoft enable this huge community to make their next gen dev platform a huge success, instead of just the moderate success it has been so far.

      • Avatar
        Richard Przybylski

        Some of the issues I run into is with FLOW and interoperability.  Additionally, BCS issues are causing huge problems because of connectivity problems.  We are moving negatively toward and SAP type of environment.  .Net is a great framework and very usable.  I keep seeing the modern interface and how easy it is to use, but custom views are still being required.  Look and feel and functionality are seriously important.  Trying to give users the capability of doing it themselves doesn’t work as well as allowing the customization needed to be effective.  I do agree that .net will not disappear in my lifetime.

    • Avatar
      Aaron Franke

      I believe this is an Apple requirement.
      But what Microsoft can do and haven’t done yet is allow building for Android from Linux. Currently you are required to use Windows and Mac to develop mobile apps with C#, which sucks for Linux users.

  • Avatar

    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?

      • Avatar

        You say that Rich, but every MS employee I’ve spoken to at conferences for the past 5 years has privately admitted that this was the inevitable conclusion. Only officially has there been this ever evolving, highly implausible story of “.NET Framework, Mono, Unity will continue to be developed side-by-side with .NET Standard tying them together”. 

  • Avatar
    Chris Martin

    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?

    • Avatar
      Charles Roddie

      I think you have the right idea. In 2021 you could create .Net Core libraries which can be widely used. But there is no serious cost to targeting .Net Standard 2.x instead of .Net Core. In 2022 they may have stopped releasing new .Net Standard versions since it only applies to .Net Core by then. So you can make a 1-line change in your project files to target Core instead of Standard to get the latest APIs.

      • Avatar
        Tuan Anh Pham

        Sorry to hear that there’s any plan on that. Why not use SkiaSharp or similars to build next big ui framework that’s a direct concurrent of Flutter that target really cross platforms (ios, android, windows, mac, linux and fushia) ?

      • Avatar
        Aaron Franke

        If you do make this, it would be awesome if it integrated with the GUI toolkits on the target OS. Xamarin apps look native on Android and iPhone, and it would be awesome for the same to apply for Windows, Mac, and Linux (GTK/Qt/either?).

      • Avatar

        … and is completely incompatible with .NET, leading to increased costs in development and maintenance as you are now effectively managing two codebases written in two different languages, rather than one.  Those who understand these business implications need a cross-platform library implementation, is who.  Those who like compounding prohibitive costs into their software development processes can continue to use Angular alongside .NET, is who.

  • Avatar
    Max Mustermueller

    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.

      • Avatar
        Max Mustermueller

        I’ve got tears in my eyes. This was the only feature I’ve really really missed in .NET, which made me jealous for other languages like C++ and I never believed it would become part of .NET because it’s a real breaking change. And today I read that it will come and even in 2020 already.
        You’re amazing, thank you so much!

        • Avatar
          Petr Onderka

          > How does WinForms in .NET Core work when .NET Core is supposed to be cross-platform?
          You can see WinForms as a Windows-only library that’s built on top of .Net Core. You can create OS-specific .Net Core libraries today, and so can Microsoft.
          > Doesn’t that just lock those apps to Windows?
          It does.
          > Why not create a new cross-platform GUI system?
          Because that would be a lot of work and it’s not clear how something like that should be designed or how it would be profitable for Microsoft.
          I am still hoping MS will do it anyway, at some point after .Net 5.

  • Johnnyxp64

    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.

  • Avatar
    Thomas Claudius Huber

    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.

  • Shimmy Weitzhandler
    Shimmy Weitzhandler

    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.

  • Avatar

    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).

      • Anthony Roy
        Anthony Roy

        We need assurances on how long on this. I would say there are tens of millions of websites that use WebForms and when everyone realises that these may not be supported they and me will not be happy. Do you know how long the original .net web form frame work will be supported until?

        Thanks in advance.

    • Anthony Roy
      Anthony Roy

      1. There are more likely tens of millions of websites that use web forms.
      2. We are like you, we have had no need to take .net core seriously because we have everything we needed in WebForms. Our main problem is that we have millions up millions of lines of code from Document scanning modules, to Web Service Data importation APIs to Advance Loan Servicing platforms to Advanced document origination systems to Custom Forms modules where clients can add in their own forms and tables etc etc and to rewrite all of these will take us many years.
      3. We have seen many fads from the original MVC frameworks to now this open source and no one really cares where the systems are hosted and I prefer windows servers because we understand them. Our systems run in a web browser and can be used on Mac or Linux machine anyway so who cares.
      4. I cannot believe MS is not going to port web forms.

  • Avatar
    Andrew Witte

    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 😉

  • Avatar
    Alexander Zaytsev

    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.

  • Avatar

    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

    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.

  • Patrick Smacchia
    Patrick Smacchia

    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.

  • Avatar
    Andrew Stephens

    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?

  • Avatar
    Aaron Franke

    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

    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

    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.

  • Avatar
    Harvinder Singh

    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

    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.

  • Hugo Ferreira
    Hugo Ferreira

    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.

  • Hugo Ferreira
    Hugo Ferreira

    .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)

    • Avatar
      Phillips, Matthew (Reigate)

      On Hacker News Rich says ‘There are not really any yet. We intend to take the Java interop that Mono already supports, improve it as needed, and make it available to other scenarios beyond just Android. If there are certain things you would like to see, I’d love to know.’

  • Chris Benard
    Chris Benard

    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?

  • Avatar
    Jason Nappi

    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? 

  • Avatar
    Gleb Krasilich

    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!

  • Avatar
    Misra, Lingaraja

    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?

  • Avatar
    Joe Amenta

    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.

  • Avatar
    Georgy Perevozchikov

    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)…

  • Avatar
    Jens Samson

    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

    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?

  • Avatar
    Eric Finch

    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.

  • Olu

    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.

  • Justin W. McCarthy
    Justin W. McCarthy

    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.

  • Avatar
    Alex Sarafian

    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

    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 !

  • Avatar
    Robert Boissy

    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.

  • Avatar
    Michael Taylor

    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.

    • Avatar
      Tsahi Asher

      You are missing the whole point of .NET Core. You can install a .NET Core application on a machine that doesn’t have .NET Core installed at all, and just bring the framework with you, as .dll files. Multiple versions of .NET Core can also be installed side by side.

      • Avatar
        Pete Wilson

        And when .Net Framework was first announced, it provided the solution to “DLL Hell” by supposedly allowing side by side installs of multiple versions ensuring apps would just work. What has changed with .Net Core to make that just work better?

  • Patrick Smacchia
    Patrick Smacchia

    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.

  • Avatar
    Ryan TremblayMicrosoft logo

    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 .

    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.

  • Avatar
    ibrahim fahdah

    The question is why the guys at Mircosoft didn’t think about .Net 5 before they worked on .Net Core/Standard since Mono and the other stuff were already there?!
    .Net 5 is just adding so much pain and confusion to companies who have been investing to upgrade to .Net Core/Standard. I have already told my boss about .Net Core and he started to get confused. I just imagine his reaction if I tell him now that .Net 5 is coming.
    Also, how about the pain software developers suffer trying to keep up with all of this new stuff because they fear of being outdated one day and lose their jobs. Many developers are using weekends and evenings to keep up!
    I wouldn’t be surprised that after few years of .NET 5, we hear that the team finding hard to maintain one platform to support everything and they decide to go back to the idea of having multiple platforms as the case now. 
    .NET 5 might still great news for lots of software developers.

  • Avatar
    FinnZan Nishi

    “The default experience for most .NET 5 workloads will be using the JIT-based CoreCLR runtime.”
    “.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.”
    Do these suggest that UWP apps will be able to choose not to use .NET native at release and some of the APIs that would prevously fail WACK will be allowed? 

  • Avatar
    Mario Blatarić

    This is interesting, but I fail to understand why we need both CoreCLR and Mono … at least longterm. Why wouldn’t CoreCLR implement the differences from Mono and be done with? 
    Is this the end-goal, while having Mono in transition period to support mobile platforms ?

  • Avatar
    Tejas Nanaware

    This is really big news and it will really bring together multiple platforms which would be fun to work. After reading this post, we could really quote Lord of the Rings as, “One framework to rule them all, One framework to find them all One framework to bring them all, And in the codebase bind them.”

  • Jerry Merchand
    Jerry Merchand

    I just want to thank M$ for the purchase of Xamarin and the move to Asp.Net Core and all of the .Net Standard work! Which makes this new .Net 5 possible. And thanks for Blazor! Now we can write the code we love and let it run on all environments including the phones! Some of the smartest moves I have seen from M$ in a decade! Now we need a unified XAML standard that will run on the new .Net 5. All M$ needs to do is make the new XAML streamlined and standard across the board and make it compile into the web assembly!! 🙂 Blazor and Razor is ok but a streamlined XAML standard that can run in the web assembly is the future of web and possibly all UI front-ends! And all of these developers need to cheer up. We get paid to write code. So start writing some code. As far as job security we have lots of it if you work hard.

  • Avatar
    Pawel Gizinski

    Hi, Can we expect release of new version of .Net Standard, which will cover more interfaces from .net Framework v5? I am about to face decision of porting to .Net Core now, but reading about coming .Net 5 release I am conerned about implications related to cupgrading again to v.5 in a year time.

  • Avatar
    Abhimanyu Rawlley

    I am an web developer. Does the advent of .net 5 imply that I can leverage my existing .net and c# skills to create AI and IOT applications after acquiring the required knowledge in the fields of AI and IOT and therefore contribute in these fields along with web development?

  • Avatar
    Federico Dutto

    Support Asp WebForms and VB .net … with the evolution of html5 standars is gonna ve to fast…For small and medium teams it is perfect and fast for development. I understand that they could propose a concrete migration or evolution .. its possible ?

  • Avatar
    Maytham Fahmi

    I was working on this repo the other day, and it contains netcoreapp5.0. I tried to google search it so I can download it for fun. My Question is it available for use as preview. If not, why adding it to the project, just curious. (check MicroBenchmarks.csproj and BenchmarkDotNet.Extensions.Tests.csproj)

  • Avatar
    D Kh

    I have been fortunate enough not to use the majority of .NET Framework pieces which have withered and died: WCF, Silverlight, WWF, ASP.Net Web Forms, and other stuff that never made any sense to anyone who knows even basics of Linux/other stacks like Node or Python. The bloat dies out, the BCL does not as things like primitives, Type/reflection, List/Dictionary/Thread/IEnumerable/Task can not really die as they are basically logically immutable concepts representing the essence of software engineering. I have no idea how people claim that they have used WCF and ASP.Net WebForms in their own projects as these frameworks never ever made any sense. This stuff was only meant to be used in the “enterprise” = “a bunch of managers who know nothing”. The comm services that WCF provided were easily replaced with alt stacks like MVC/API (which we have used back in 2007) or projects like ServiceStack. Overall it seems that MSFT is on the right track now doing things more “sane” way similar to Linux-first systems (Node etc..) As for WCF support – it is impossible to carry all of that dead weight indefinitely. Too bad that most .Net devs until recently have been too close minded and did not follow Ruby, Node, Erlang, Python and other stacks that already had all of the “modern” concepts we see in .Net Core today back 10+ years ago.

    • Avatar
      Vladimir Neverov

      This is quite sad that such frameworks like WCF do not make sense for you. Have you ever had to write a service that will have to “announce” its presence to other services after it starts ? Did you have to call several services as part of a single transaction? How about services that discover other services, services that route calls to other services? How about calling services over various communication channels (TCP,Net pipes, UDP) without changing your code. Please look into the topic more thoroughly before equating WCF to MVC/Web API.

    • Avatar
      Jason Rosenthal

      I was so excited when they were going to truly unify everything into a single dot net that runs on multiple platforms. Then you read the “Support for Leveraging” fine print and they are just doing interops and islands for everything and resulting in what I predict to be an even bigger mess than what we have now.

      I’m looking at Flutter or React Native to get something done today. I’m leaning to towards Flutter right now because some of the old Microsoft guys are on that project. I would like to use UWP with WinUI but I still need to target Windows 7.

  • Avatar
    Lorin Kundert

    The PR looks good and the charts make sense, but the implementation is lacking, we are being told not to develop Winforms apps using .Net Framework since its going bye bye, but we are at least a year away from a working solution that can replace that, a shocking example was the release of NetStandard2.1 and NetCore3.0 which dropped support for the .Net Framework, so that those of us who are invested in Entity Framework are screwed, we are told to stick with EF Core 2.2 which is buggy, we were told to wait for 3.0 and they will be fixed, then just moments before being released we are told there is no support for .Net Framework. So do we sit here for a year or more until we can use these new things? Or do we do as my employer wants me to do and drop Windows altogether and go with GTK or QT on Linux, it is now believed that the pain points are higher than the pain of migrating to Linux, why drop support for key frameworks until you have a working replacement in hand?

  • Avatar
    Ramesh Venkataswamy

    ASP.NET and its controls are the best, wonder who had suggested to remove from .NET 5.0

    When it comes to others front end developments have so much issues and its not even comparable to ASP.NET.

    ASP.NET Has code behind by default, only HTML is sent to browser, and we can praise so much about it.

    Would be great if ASP.NET if it is enhanced, with all the controls having AJAX response and just provide one control like Single Page control, which does all the required postbacks, if they don’t want it can work as it is now.

    It is the same mistake like VB was discontinued, look at Java no change and that’s why the count of developers is many.

    • Anthony Roy
      Anthony Roy

      Ramesh, I agree with you. We have been using for years and managed to upgrade it from VS 2008….to VS 2019 without any major issues. Razor looks awful, plus I am worried that it could take us years to replace the system and then be in the same boat in 10 years.

  • Herman Van Der Blom
    Herman Van Der Blom

    Well, as “True” .NET developer I did not gain anything by the “.NET Core” thing. Its just a big mess. Microsoft was forced to embrace the “Linux” saga and then left the “True” .NET developers behind in the .NET 4.x world. To make it all just a Joke we went from 4.x | Core -> 5.0.

    • Avatar
      Steven He

      I don’t think so, most of .NET Framework technologies have been migrated to .NET Core. Maybe there’s some pain to move existing projects from .NET Framework to .NET Core, however, languages and most APIs are compatible so I think in many cases it’s not so complicated.
      At least I’ve migrated many of my .NET Framework projects to .NET Core, and the migration experience is not bad.

  • Avatar
    Nigel Pearce

    So I maintain a Windows desktop client app developed using WPF and targeting .Net Framework 4.6.1. It also makes use of a number of third party tools that provide features as diverse as webcam video recording, DSLR camera control, face detection and integrated web browsing (CefSharp).

    Is there a way forward to .Net 5 for a project of this nature?

  • Avatar
    Erick Vils

    Richard, why Blazor server-side .NET 5 says “yes” and WebForms server-side “no”?

    I know that port Web Forms is an additional effort, but we are talking about Microsoft, a company that concern about compatibility and legacy.

    For me (27 years programming), Blazor isn’t so mature as Web Forms.

    I’m the CTO of an ERP software company, with more then 11.000 webforms source code files running well on .NetFramework 4.8 with everyday maintainability and support.

    To force all legacy projects around the world to Migrate the code probably will be more huge than Microsoft add support to webforms in .Net 5.

    I hope Microsoft concern about that!

    • Anthony Roy
      Anthony Roy

      Erick, I agree with you, we have built up a great software platform over 12 years and have a great competitive edge over our competition and now to find out we need to shift to Razor .net core would mean we have to start almost again. Crazy we love webforms and do not need anything else.

      Kind regards

  • Todd Menier
    Todd Menier

    I wonder if this simple, common-sense name will actually stick or if marketing will hop in and confuse matters like they did with ASP.NET 5. (ASP.NET Core. Runs on .NET Core or Framework, and isn’t really the “core” of anything…huh?)

  • Avatar
    Hire Matha, Vinayaka

    Any updates on .NET Standard, will it continue to be a library development standard going forward on .NET 5 and above? OR any newer “standards” for library development are coming up!

    Will my .NET Standard libraries will be functional when I refer them on .NET 5 and above? (given that I need to upgrade my libraries following higher versions of .NET, as things progress)

    How this will be a help: I will continue to ship my libraries on .NET standard, clearly making use of its Platform targeting capabilities(FW, Core, .NET5, etc.) and only upgrading my consumer applications like Web, of course, within .NET standards reach.

  • Avatar
    Renato Katalenić


    Which of these two option (.NET Framework or .NET Core 3.1) is better to choose for long term application in context of migrating to .NET 5 or better say to .NET 6 LTS.

    I know that porting .NET Framework to .NET Core can be a pain, but what is with migrating applications from .NET Framework and .NET Core to .NET 5 or .NET 6 LTS?
    I did read that .NET 5 is considered as successor to .NET Core, does this mean that .NET Core will be easy to migrate to .NET 5 (i mean easy as just to reference .NET 5)?
    What if we skip migrating from .NET Core 3.1 to .NET 5 and decide to migrate to .NET 6 LTS?
    Will we need to migrate from .NET Core or we can stay on it?

    Any thoughts would be helpful.

    Thank 🙂

  • Anthony Roy
    Anthony Roy


    Hi Microsoft .net team,

    I think you are making a big mistake by saying .net 4.8 is going to be the last update to the original webforms framework.

    We like other successful companies have built up a successful business developing .net applications from VS 2008..10..12..13..15..17 to VS 2019 taking the time to build our systems properly so that we could keep up todate with newer version of visual studio / SQL. We never used the MVC as it was flaky early on and no where near the previous platform of Delphi, so we built our own frame work and have added on more on more features while upgrading each year from .net 2 to 3.5 to 4.5.1 to 4.6.2 etc etc and I am dumbfounded that you will not be porting over WebForms for people who want these and only need to develop on windows servers and IIS as any web browser can use these platforms including Safari and FireFox etc. WE DO NOT WANT TO START AGAIN – THIS LOOSES US OUR COMPETITIVE ADVANTAGE. We currently use MS technology, MS hosted servers and MS SQL, IIS and even though we love MACs, I have no intention of developing on them, plus our clients can use their Mac as our software is completely web based. Open source does not pay the bills, we prefer to pay for things, as free means out of business or unsupported in the future. Companies like us who have developed large decent and fast systems that companies use to process billions of pounds worth of finance and we are happy with WebForms and we have built own own frameworks and fast speedy systems and do not want to start again. We moved from Mainframe systems/Dos using apps like Dataease to Windows software like Delphi and then .Net (3 hits in a row as these became the leading software platforms), plus we only moved because windows was better than does and the web solved download and installation issues, plus could be used anywhere, but the new .net frameworks .net core look a mess. There is no clarity, too much choice and you are changing things to fast and then scraping things too fast. I am really worried because we could start to redevelop only to find that you scrap what used to be the next best thing. Why would someone want to start again writing millions upon millions of lines of code when the things they have works perfectly. Personally I have seen a number of MVC and Data middleware systems and a lot of them are bloatware which actually slow down systems and data access, plus they become unsupported quicker. Not porting webforms and giving your original core of developers a future means you are making us poorer, less competitive and less productive, plus you are alienating your hardened core of .net developers who have successful applications. You are Microsoft surely someone can port over web forms, even if it stays on windows only and support a working platform. We gain no advantage of starting again.

    Please rethink, about this i.e.
    1. Why are you not porting WebForms from the original .net system after .net 4.8, I was told you would be merging the platforms.
    2. .net Core is still flaky and third party providers who’s components we licence have not all fully caught up.
    3. The decent software writers do not need change, we just need security patches, everything else we can write ourselves.


    • Avatar
      Reinhard Moosauer

      hopefully I understand your concerns correctly.
      You have a lot of investment in WebForms, which is great! From what you write I understand that you are afraid of losing some of that investment.
      Why do you have this feeling? As I see it, .NET 4.8 is not going away in the next 10+ years.
      The .NET core flavor is still quite new and this is clearly giving you the feeling that some of it still flaky.

      I would recommend to rest assured that .NET 4.8 will run the business for a long time coming!
      And the .NET core world is being built in parallel for all the other stuff, which would have never fit the development model of the classic framework.

      Maybe it seems that some of the ‘cool new stuff’ is not coming to the classic framework.
      Is that really a big deal? It seems to me that this cool stuff is not that important for your competitive advantage. Or is it?
      Your third party component providers will have this covered!

      And in the end, a decision to not port a classic framework is never set in stone!
      You can see this right now with the WinForms framework. (

      Actually, for me, the .NET core world is giving more confidence about the future of C# and all things Microsoft than all incremental updates to the classic .NET framework in the past eight years (since .NET 4.5 []).
      You have to admit that this monolith is not a great example of agility.

      I would love to hear from you and wish you great success with all your ventures.

  • Avatar
    Benjamin J. Copass

    I appreciate the backwards compatibility that Microsoft has provided with the various .NET releases. But a big unifying release might still be an opportunity for breaking changes.
    Some I would really like to see
    – IList inherit from IReadOnlyList
    Some would be nice for future consistency
    – Different Exception constructors should be consistent in their messageText/parameterName order
    And some might be nice if they can make performance improvements
    – If not supporting ‘lock’ on all class types can save 4 bytes per class instance, I would support it.