.NET Core is the Future of .NET 

Scott Hunter [MSFT]

We introduced .NET Core 1.0 on November 2014. The goal with .NET Core was to take the learning from our experience building, shipping and servicing .NET Framework over the previous 12 years and build a better product. Some examples of these improvements are side-by-side installations (you can install a new version and not worry about breaking existing apps), self-contained applications (applications can embed .NET, so .NET does not need to be on the computer), not being a component of the Windows operating system (.NET ships new releases independent of the OS schedule) and many more. On top of this, we made .NET Core open source and cross platform. 

.NET Core 1.0 was primarily focused on high performance web and microservices. .NET Core 2.0 added 20K more APIs and components like Razor Pages and SignalR, making it easier to port web applications to .NET Core. And now .NET Core 3.0 embraces the desktop by adding WinForms, WPF and Entity Framework 6 making it possible to port desktop applications to .NET Core.  

After .NET Core 3.0 we will not port any more features from .NET Framework. If you are a Web Forms developer and want to build a new application on .NET Core, we would recommend Blazor which provides the closest programming model. If you are a remoting or WCF Server developer and want to build a new application on .NET Core, we would recommend either ASP.NET Core Web APIs or gRPC, which provides cross platform and cross programming language contract based RPCs). If you are a Windows Workflow developer there is an open source port of Workflow to .NET Core 

With the .NET Core 3.0 release in September 2019 we think that all *new* .NET applications should be based on .NET Core. The primary application types from .NET Framework are supported, and where we did not port something over there is a recommended modern replacement. All future investment in .NET will be in .NET Core. This includes: Runtime, JIT, AOT, GC, BCL (Base Class Library), C#, VB.NET, F#, ASP.NET, Entity FrameworkML.NET, WinForms, WPF and Xamarin. 

.NET Framework 4.8 will be the last major version of .NET Framework. If you have existing .NET Framework applications that you are maintaining, there is no need to move these applications to .NET Core. We will continue to both service and support .NET Frameworkwhich includes bug, reliability and security fixes. It will continue to ship with Windows (much of Windows depends on .NET Framework) and we will continue to improve the tooling support for .NET in Visual Studio (Visual Studio is written on .NET Framework). 


New applications should be built on .NET Core. .NET Core is where future investments in .NET will happen. Existing applications are safe to remain on .NET Framework which will be supported. Existing applications that want to take advantage of the new features in .NET should consider moving to .NET Core. As we plan into the future, we will be bringing in even more capabilities to the platform. You can read about our plans here. 


Discussion is closed. Login to edit/delete existing comments.

  • David Hunter 0

    Any news on allowing C++/CLI to target .NET Core. Hopefully your not going to leave all of us hanging given that there is no viable alternative to C++/CLI for calling native C++ from .NET ( please don’t suggest PInvoke! )

    • Gavin Williams 0

      Why do you not consider Windows Runtime Components using C++/CX or C++/WinRT ?

  • Greg Sohl 0

    My previous comments were feature specific. But I should have started with – Thank You! Getting us back to one framework is where we need to be. The general direction is right. Now, how to avoid leaving the important pieces behind just because they aren’t in the news anymore. The reason for that – they just work, and need to continue to.

  • Jon Miller 0

    Thanks for throwing Web Forms developers under the bus and recommending Blazor as a replacement. Something that is basically only experimental at this point. Time will tell whether it is another Silverlight. Stupid move not supporting Web Forms when you support Windows Forms and WPF.

    • Tom McDerp 0

      Wcf guys – which includes microsoft are equally screwed. My contacts at ms paint a picture of badly mismanaged project so this doesnt surprise me. I have beers on this thing not quite panning out as advertised.

  • Tom McDerp 0

    “If you are a remoting or WCF developer and want to build a new application on .NET Core, we would recommend either ASP.NET Core Web APIs or gRPC (Google RPC,”
    Then you have failed to listen to your customers. I adivse you to go f yourself. Because that is what you are telling partners and enterprise customers with millions of dollars invested in wcf. The backlash will cost Microsoft with this attitude and abandonment.

  • Zachary Parton 0

    Got my torch and pitchfork to join in with the WCF folks. Give us the code if you don’t want it anymore.

  • christos karras 0

    This means we need a migration plan for any .Net Framework feature and library that won’t be ported to .Net Core. There should be a centralized document (on docs.microsoft.com and/or github) listing .Net Framework features/libraries and their status for .Net Core:
    – Already available, without breaking changes
    – Alternative available, but there are breaking changes (Name the alternative and reference a document for migration guidance)
    – Planned for .Net Core 3.x
    – Won’t be available

    Just a few examples I can quickly think of:
    – WCF
    – ASP.Net WebForms
    – GAC
    – Entity Framework 6
    – Owin
    – Asp.Net MVC
    – Asp.Net Web Api
    – COM Interop
    – Windows Forms
    Yes I know some of these are/will be available but I know it from searching on forums, UserVoice, etc, not from any cannonical source. There needs to be an official centralized exhaustive list with all this information, so that we can start planning and refactoring affected apps.
    Also, if there are too many unsupported features/libraries on .Net Core, it may be implausible to migrate legacy apps to .Net Core, so it’s more likely these applications will get stuck on .Net Framework 4.8 and Microsoft will need to keep supporting .Net Framework 4.8 for decades, until all these legacy applications have been rewritten (if that ever happens)

  • Mottor Demottor 0

    Make ONE Exe for console applications possible. I do not want to hear questions like: “Why are you deliver 50 DLLs? Java has only one jar.”
    Isn’t possible to remove all unused code from all DLLs and make one exe?

    • Michael Taylor 0

      .NET Core 3 [supports](https://docs.microsoft.com/en-us/dotnet/core/whats-new/dotnet-core-3-0) this starting with preview 5. You can read the documentation [here](https://github.com/dotnet/designs/blob/master/accepted/single-file/design.md). Note that even with Java you cannot simply “run” a jar file. If you don’t have JRE installed then it does nothing. Supposedly (not tested) this isn’t an issue for .NET Core.

    • Alan Bourke 0

      Fody Costura?

    • Scott Waye 0

      CoreRT can create a single contained Exe. IL Linker will remove unused code.

  • Kyle Brown 0

    For people talking about WCF and WebForms support in .NET Core
    “Existing applications are safe to remain on .NET Framework which will be supported.”

    • christos karras 0

      “Will be supported”…. until when?

      • Gavin Williams 0

        At least until Visual Studio is rewritten for .net core, so maybe around 2030? Who knows. If they can rewrite Visual Studio by then, I don’t see anyone else having a good excuse as to why they haven’t moved off .net framework.

        • christos karras 0

          According to https://www.tiobe.com/tiobe-index/ COBOL’s current popularity is close to R and even above TypeScript. It’s plausible .Net 4.8 will have a similar fate in 2050 if Microsoft doesn’t provide a realistic migration path.
          If there’s no migration path, then the only option will be a costly rewrite, which won’t happen if there’s no benefit.
          For example, there should be an intermediate version of .Net Framework that supports ALL of .Net’s 4.x libraries AND .Net Core’s 3.x libraries, to allow progressive migration of .Net framework features to more modern alternatives. It would also allow re-implementing some legacy libraries as adapters over .Net Core alternatives. Then eventually there could be a unified .Net, but .Net 5 is too soon, perhaps .Net 7.
          It’s utopic to believe that an organization will simultaneously convert its code to replace (for example) WCF, ASP.Net Web Forms, and COM Interop, that’s a pretty good “excuse” if you want to call it an excuse.

        • Oliver Ulm 0

          Visual Studio relies on parts of the full Framework (like WPF) that will be supported in .Net Core. WCF won’t. It’s likely we’ll see VS on .Net 5 rather soon.

    • Przemysław Wasylko 0

      Frankly speaking I am annoyed and sick 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 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.

  • SuperCocoLoco . 0

    Without Visual Basic in ASP.NET Core or in Blazor is imposible to migrate to .NET Core or .NET 5. I know C# but i prefer Visual Basic to code, more clear code and more readable and if i want to use a C-Style language i use C++, Javascript, etc. But for .NET I refuse to code in C#. I don’t like it and I will never use it.

    • Elliott Ward 0

      I find myself in a similiar situtation, I perfer Visual Basic over C#, and my company and I no longer have faith in Microsoft’s “it will continue to work great” statements. Look at all these technologies we have invested in WCF, Silverlight, .Net Standard and so many others only to be left abandoned and wishing we have choosen a vendor with more integerity to it’s users.

  • sballard@netreach.com 0

    Does this mean that Web Forms code won’t be able to run on .NET 5? If not – I’m not sure what the licensing situation is for the .NET Framework source code, but is there any prospect of a community project to get the Web Forms code running within v5 if MS isn’t going to do it officially?

Feedback usabilla icon