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

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

  • Wil Wilder Apaza Bustamante 0

    This comment has been deleted.

    • Mike-E 0

      WCF isn’t strictly web, though, is the point.  No one is going to invest in a new system when the old system was abandoned via confusing messaging and dysfunctional developer relations, is the point.  Investments have already been made and budgets do not exist to jump onto the new shiny ball, is the point.
      Also, if you read carefully, no one is complaining about Silverlight but are referencing it as the defacto example of poor product handling and subsequent terrible developer relations.
      All that said, open sourcing all of these products would solve a lot of problems and shut up a lot of grieving developers. 
      Is the point. 😆

      • Sami Al Khatib 0

        I wasn’t speaking about rewriting huge existing systems. As stated before, in the opening post and by many commentens, full .NET-Framework is going to live on and can always be used to develop new and existing applications.

    • Przemysław Wasylko 0

      Dear SamiMixing WCF with Silverlight and Web Forms in one bag prove how *little* you know about those technologies.
      While Silverlight and Web Forms are strict Microsoft vision on how to do certain things, WCF is server side technology for backend development which follows industry WS-* standards, open stardards, developed Microsoft, IBM and other bodies. Your statement is completely misleading readers.> Those technologies never followed web standards like ASP.NET WebApi didtaking above into consideration you completely have no idea about matter you are trying to respond to

      • Sami Al Khatib 0

        Dear fellow developer, 

        I wasn’t mixing anything, I just know that people used to love WCF services with Silverlight, because they can be used like plug in play in those applications. In fact, I have been working and writing WCF services with SOAP and REST for a while and I know there are some companies that baked those protocols and that there is an old, legacy, not maintained, W3C definition of those “standards”. My point was not to say to jump to the latest shiny technology, but that those technologies are not advancing anymore and there is no need to make them compatible when the full dotnet framework is gonna exist forever because of all the existing applications. Before you decide to say that people know “little to nothing”, sit back and think properly again. 

      • Sami Al Khatib 0

        Dear fellow developer, I wasn’t mixing WCF with Silverlight nor with Web Forms. I just know people started using those together, since I worked on WCF Services using SOAP and REST + Silverlight Frontends. While you are right that a few companies backed WCF and WS-*, it has never been a widley spread standard and was abandoned rather quickly while other standards lived on. JSON was already heavily used when WCF was introduced in 2008 but WCF natively used XML. I hope you get the idea now.

    • Jon Miller 0

      Hey everyone, Sami rewrote his 5 line hello world app. Why can’t you rewrite your millions of lines of code? Don’t confuse new with better. Web Forms works better than ASP.NET Core for intranet apps like the one that I’m working on. Microsoft is telling Web Forms developers to use Blazor, an unreleased product that is barely alpha. The post Web Forms way of doing things’s problem has alway be a lack of UI controls. That hasn’t changed for the past 10 years. ASP.NET MVC was a dumbing down of what they already had. For all practical purposes, it was just a rip off of Ruby On Rails. The ASP.NET team is doing a horrible job IMHO. It is the worst part of the platform.

      • Sami Al Khatib 0

        Have you heard about Javascript / ECMA Script for frontend development by any chance? I am sorry that you have to work on a code base with million lines of code, where the main framework used is web forms, that must be horrible. I wasn’t confusing new with better while in fact I wrote intranet applications using Core WebApi with windows authentication and dedicated frontends. For me it worked like a charm and I can promise you those application were not just displaying “Hello World!”. The ASPNET team is doing a great job, don’t put your anger and fear of learning something new on Software you don’t know how to use. 

  • Nick K 0

    This is extremely disturbing.  Each “long term support release” of .net core is only supported for 3 years and .net core is the future?  I work on an application that has a 2 year release cycle for a new version … Can someone explain to me how .net core is the future when I still have paying customers running 10 and 20 year old versions of my software?  Are you basically saying that the future is in disposable crappy smartphone apps that get updated every week and users uninstall after getting bored with them?

  • Will Woo 0

    So, show us an example of a Core/WinForm app with a treevew, and some other controls. Describe how that app is deployed, updated, etc.
    Based on this article: figuring out win development’s future is like trying to find faces in the smoke from Chernobyl.

  • Cesare Perani 0

    What about C++ ? 
    Thank you

  • Ken Domino 0

    What is the future of Net Standard? I was planning to rely on its existence for my compiler and framework for the GPU.

  • Michael Taylor 0

    How does this play out for environments where you have no control over the runtime? For example SQL Server supports managed code in the database and SSIS relies on components written in managed code. SSIS script tasks are compiled as well. In order to build any of these today you have to target the version of .NET that the SSIS runtime is using. Moving forward is SSIS (and SQL) going to support .NET Core? What is the timeframe for this? How will existing components/scripts work that still rely on Framework? Can they run side by side?

  • Peter Gummer 0

    What, still no Code Contracts?

  • selvakumar palanisamy 0

    WS security is not supported by WCF on .NET Core. Having no support for this is a major set back for us, most of our existing web services requires this security in order to consume them.
    For reference:
    <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:cus="http://tmnas.com">
    <soapenv:Header>
    <wsse:Security xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/07/secext">
    <wsse:UsernameToken xmlns:wsu="http://schemas.xmlsoap.org/ws/2002/07/utility">
    <wsse:Username>XXXXXX</wsse:Username>
    <wsse:Password Type="wsse:PasswordText">XXXXXX</wsse:Password>
    </wsse:UsernameToken>
    </wsse:Security>
    <soapenv:Header/>

  • Mark Fonnemann 0

    For those of still developing strictly desktop applications, the lack of a cross-platform UI toolkit/framework in .NET 5 is going to be really frustrating. At the very least, I don’t understand why Mono’s port of WinForms can’t be leveraged as at least a starting point for this effort.

Feedback usabilla icon