.NET Core is the Future of .NET 

Scott

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

Summary 

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. 

122 comments

Comments are closed. Login to edit/delete your existing comments

  • Nerk

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

    • Lee Butler

      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

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

    • Scott HunterMicrosoft employee

      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

        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

          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.

      • Nerk

        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?

        • James Foye

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

        • SuperCocoLoco .

          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.

  • Sam Covington

    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

    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.

    • Evgeniy Alexandrov

      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

        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

          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

      +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

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

    • David FowlerMicrosoft employee

      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

    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.

  • PandaSharp

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

      • PandaSharp

        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

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

    • Jon Miller

      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

        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.

    • Tom McDerp

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

    • Jens Samson

      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

        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

      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.