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

  • Nerk 0

    What about ClickOnce? Will that be a supported distribution system for .NET 5 desktop applications?

    • Lee Butler 0

      I’m hoping they have a different solution. One that is as easy to use as Clickonce but actually works properly consistently. Clickonce usually mostly works, but it’s a pain in the ass when it doesn’t. Things like all user installations and/or domain deployment would be nice too. Clickonce is awesome and I use it a lot, but it’s not the most reliable thing in the world. 

      • William Feely 0

        Speaking of which, do I notice that Google Chrome uses ClickOnce to install when installed via Internet Explorer?

    • Scott HunterMicrosoft employee 0

      We are going to recommend MSIX for installation and support for MSIX will be added for Windows 7 so it should work on all the platforms you that .NET Core runs on.

      • Greg Sohl 0

        Would prefer to never use any installation system that includes the letters MSI. If I never produce an install that has to follow its insane rules again it’ll be too soon.

        • Warren R 0

          MSIX is a wholly different beast from MSI. They’re ZIP files with a manifest, like App-V.  Try to not obsess over the similar lettering; arbitrary self-restrictions like that might be career-limiting down the road.

        • James Foye 0

          I second that.

      • Mystery Man 0

        Hi. When will MSIX be added to Windows 7?

        • Alan Bourke 0

          And Windows 10 versions pre 1809?

      • Nerk 0

        Will MSIX work in the same way as ClickOnce? We deploy all our applications to a central server, then our users run the ClickOnce setup.exe from there so that they always get the latest version. We deploy our applications with the “available online only” setting so we can do regular updates without the users having to do a re-install. Will MSIX support that scenario?

      • Charles Roddie 0

        Why? Windows 7 goes EOL in January 2020.

        • James Foye 0

          That doesn’t mean anything. It will be still be used for many years to come.

        • SuperCocoLoco . 0

          All of our customers prefers Windows 7 without support (with a good antivirus and firewall) than Windows 10 with support. Me too.
          Users don’t Windows 10 with all of the telemetry, with ads, with mobile apps and with an ugly and bif smartphone user interface with verey very very less information density, lack of contrast, color and missing options in Control Panel moved to Settings smartphone style that is unuseable and with less options and features and without a real Start Menu.

  • Drew Freyling 0

    What is the “recommended modern replacement” for connecting to an endpoint you don’t control that has WS-Security in WCF? https://github.com/dotnet/wcf/issues/2605

    • Greg Sohl 0


    • Duc Thuan Nguy 0

      Or for applications that are providing such endpoints that thousands of clients are connecting to 🙂

    • Tom McDerp 0

      i dont get the reasoning behind the refusal to move wcf forward. 

  • Sam Covington 0

    Deploying asp.net core isn’t as smooth as in the full framework, which is basically xcopy deploy. In addition to lacking xcopy deploy, a reverse proxy is required, and MS doesn’t make one available.
    While this is understandable on linux, it makes less sense on the windows platform which we would think would have an advantage.
    Is there any thought being given to making deploy easier on windows?

  • Greg Sohl 0

    Please port WCF. MS led us here.  We followed and invested a lot into it. Please don’t leave us hanging / porting to something so much less.

    • Ian Marteens 0

      Agreed. WCF is a must.

      • Luigi Zambetti 0

        I think it’s definitely time to switch to WebAPI Core 2.

    • David Blanco 0


      • Evgeniy Gorbovoy 0


    • Evgeniy Alexandrov 0

      Agreed. We’ve got Web API support and some RPC support via gRPC over HTTP, but no XML/JSON-RPC flavors, no RPC/IPC over TCP or NamedPipes other than raw TcpListener/NamedPipesServerStream. Support of WS-* is extremely limited and this is a showstopper for a lot of people, especially WS-Security and WS-Trust. WS-Discovery via UDP in local networks is almost a lifesaver for multiple scenarios.

      • Jon Miller 0

        As long as you are planning to retire before Microsoft drops support of Framework 4.x, you are good to go. Other than that, the cool kids will tell you, just rewrite everything. And evaluate other platforms before doing so.

        • Tom McDerp 0

          Wcf is a hell of a lot more than just rpc. The fact that he is equating it to that demonstrates that he doesnt even understand his company’s own technology/frameworks. I guess biztalk sever is dead now with wcf gone.

    • Oliver Ulm 0

      +1 – there needs to be proper migration scenario that allows us to keep compatibility with endpoints on the other end (both server and client)

  • Fabion Burke 0

    Is there a replacement for WCF Web services? gRPC does not allow for Web browser clients to function directly. 

    • David FowlerMicrosoft employee 0

      If you’re not explicitly trying to use SOAP as a protocol then an ASP.NET Core REST API is a fine alternative. If you want generated clients then you can look at using NSWAG to do so.

  • John Fedak 0

    WCF is a show stopper for us.  Our comm stack is both hugely stable (and took us years to get to that point) and has to interact with external SOAP services.   Porting that to something else is a non-starter for us.

    • Tom McDerp 0

      Same here but microsoft refuses to listen or address this.

  • Kexy Biscuit 0

    Well, what about C++/CLI?

  • PandaSharp 0

    what about a XAML standard that works cross platform? specially between xamarin.forms and uwp?

    • Charles Roddie 0

      What’s the advantage?

      • PandaSharp 0

        only one XAML code to know and write for your app: xamarin.forms and UWP (eventually also for WPF, Web…)
        the eases of what you’re doing now with xamarin.forms for android and ios could be extended to all platforms

  • Matthew Hughes 0

    Whats the migration strategy for WebForms? We have dozens of commercial applications – you have a WinForms a migration path.

    • Jon Miller 0

      They want to use Blazor instead, an experimental as of yet unreleased framework along the lines of Silverlight that they will no doubt yank support for a couple years down the road.

      • Eric Blankenburg 0

        Blazor is not “along the lines of Silverlight”.  Blazor has two hosting models: 1.) server-side which communicates with the browswer using Signal R, and 2.) client-side which runs on an open standard platform called Web Assembly.  Web Assembly is an open W3C standard developed by Google, Microsoft, Modzilla, and Apple. Blazor is not a plug-in like Silverlight.

      • Matthew Hughes 0

        Hmm, yea doubt thats going to work.

    • Tom McDerp 0

      Same stategy for wcf. They want us to fck off or blow millions porting .

    • Jens Samson 0

      What is the migration strategy for L2S ?  Don’t say EF, because that is way too complex, for us L2S just works, no configuration and good enough performance.

      • Matthew Hughes 0

        Hey Jens, I hear ya we used L2S for quite some time, take a look at DevExpress XPO- it works in a similar way, it’s what we ended up going with.

    • David FowlerMicrosoft employee 0

      There’s no easy migration path for WebForms to .NET Core and as the post says .NET Framework will be supported as long as windows is supported so unless there’s an urgent need to, I wouldn’t bother attempting to port your webforms apps over to ASP.NET Core. Now if you want to take advantage of other things in .NET 5 and you’d like to keep the same webforms style of application (controls, etc) and are willing to do a re-write then look at Blazor. Blazor though is by no means a port, it’s a rewrite.

Feedback usabilla icon