.NET Core is the Future of .NET 

Scott Hunter [MSFT]

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

  • Avatar
    Duc Thuan Nguy

    Please give WCF a second thought. It is probably the most requested feature in this comment section. Moving to another stack is not an option for many who need to maintain enterprise applications, and staying with a dead framework (no matter what you say about .NET 4.8, it is dead) is equally bad.

  • Yuri Bond
    Yuri Bond

    How about package/assembly hell that .NET Standart and .NET Core brings with them?
    In good old days of .NET Framework you write your application against particular version of framework, install this framework on target machine with installer provided by microsoft and it works. All assemblies that are part of .NET Framework were istalled and later updated by microsoft.

    With .NET Core you only get some assemblies with installer, rest you need to destribute yourself as if they 3-rd party libraries even though they start with System… . They never updated automaticaly and it becomes problem for writer of software to update them.

    Then the package hell. All assemblies distributed as separate packages even though they should be part of framework. 
    Packages have non-rigid dependensies (like  X >= 1.0) but at the same time, assemblies inside packages have strong references.
    This lead to constant need of Binding redirects. So Microsoft took worst from Java, where jars do not have strong name, and implemented this with extra steps through binding redirects. 

    package/assembly hell in .NET Core is much worse now then it ever was with .NET Framework.
    It maybe a future, but very painful one.

    • Avatar
      Daniel Sturm

      Simple xcopy deployment works perfectly fine for .net core, much better than it ever did with the full framework. You seem to be doing something wrong if you have to manually copy assemblies around. Are you using the build output instead of building a deployment?

    • Avatar
      Jon Miller

      Welcome to the wonderful world of Microsoft parrotting the problems of other systems. Just like when they copied Ruby On Rails to ASP.NET MVC.

    • Avatar
      Daniel PlaistedMicrosoft employee

      .NET Core handles assembly loading differently and does not require binding redirects.  .NET Core did suffer a bit from package hell, especially in the 1.x releases, but that should be much improved in .NET Core 3.0.

  • Avatar
    Olivier

    You said: “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 Framework, ML.NET, WinForms, WPF and Xamarin. “ 
    Does that mean no investment for UWP? What’s the best option to build a NEW LONG TERM LOB desktop application on Windows 10? 
    Powerful WPF but without clear investment from Microsoft to modernised this old platform, for example no touch friendly controls for devices like your own Surface?
    UWP? But Microsoft doesn’t clearly say that it’s the future…
    In 2020, you should have 1 billion Windows 10 in production (plenty of them with a touch screen), superb tools like visual Studio, a very good language: C#, a new powerful framework: .NET 5 but nothing to develop modern and robust application for your main platform: Windows. Do I miss something here?

    • Avatar
      Gavin Williams

      [Edited] Their lack of clarity is a bit confusing. They are saying Windows is now the platform and UWP is a UI framework. But then they say UWP will use .net core instead of .net native and coreclr. UWP has been THE PLATFORM for the past few years and it has suddenly been replaced by .net core. What’s the point of UWP now ? I don’t get it.

      • Avatar
        Charles Roddie

        This is not a lack of clarity on Microsoft’s part. Some .Net devs are just confused about what a runtime is and what a UI framework is. UWP is a UI framework. It will use .Net 5. It is not being replaced by .Net 5 because .Net 5 does not include UWP. Just as I am using a keyboard to write this post, but I am not being replaced by my keyboard.

    • Olu
      Olu

      People are really angry that things are quite mixed up at Microsoft. As for UWP, the future is in Windows UI (WinUI), and it’s a bait for the lovers of WPF and Windows Forms. As long as they don’t hear UWP, they are kinda happy. But what they don’t know is that WinUI, XAML Islands, Fluent Design are the way to go with anything native UI at Microsoft. So, UWP is going nowhere. It is alive and well. It only got a new purpose. Tell me, when you’ll be coding with WinUI or XAML Island in WPF, are those still WPF controls that you can call in your code-behind? Not really, or better, let’s say no. You would be calling WinUI elements in your code-behind. Eventually, the differences between UWP, WPF and Windows Forms would all be blurred out, as long as WinUI would be what you’ll be dealing with. There are changes to the runtime too to make these changes happen. Maybe when the next Visual Studio after VS2019 comes out and with .NET 5, we would see how this plays out. For now, my personal choices when it comes to “new” apps development are WinUI/UWP, SPA/PWA (cross-platform) web app (using Blazor, a custom one I’ve been working on that can be integrated with any of Angular/React/Vue/Knockout/etc. that have inbuilt data-binding feature, if Blazor doesn’t satisfy me and because it is not released yet and I don’t really like how Angular/React/Vue/etc. assume to know everything you wanna ever do, or whatever fits what I want to achieve, and with ASP.NET Core server-side) and Xamarin.Forms (when PWA can’t do what I wanna achieve on a more performant cross-platform side). Btw, of course, I would use any of Angular, React, Vue or Blazor if a business client or workplace demands it. I would also do native Android, WPF, Windows Forms, etc. development. if a business cleint or workplace demands it.

      • Olu
        Olu

        I make predictions out of excitement, but it seems Microsoft is good at disappointing me 😀 But seriously, about UWP, I strongly feel it’s not going away, even though its features are being brought into WPF and Windows Forms. See UWP as Microsoft’s own main and futuristic native app development platform. See Xamarin.Forms as Microsoft’s cross-platform app development platform because it supports Android, iOS and UWP too, among others. So, it’s more like…if you want to target Windows only with your app, use UWP/WinUI (because, even WPF and Windows Forms will be using WinUI but would not be as good as UWP), and if you want to let your app go native cross-platform, use Xamarin.Forms (and you’ll still get UWP too). It’s that simple or confusing.

  • Avatar
    George Danila

    Ignoring WCF will be a big mistake – a lot of enterprise solutions developed on the .NET stack in the past 10 years make heavy use of this technology.

    • Tom McDerp
      Tom McDerp

      They have committed to it at this point.  Microsoft does not care about abandoning customers or developers. This isnt a new problem. Cough silverlight. The folks that jumped on service fabric w wcf really got taken for a rogering.

  • Neil Walker
    Neil Walker

    I thought I read yesterday that version 5 was the single and only future version of  .net, kind of implying full and core were being merged. So migratingfrom full to 3 might be a bit premature given it might be different again when we get there next year…

    It also said the word Core was being removed from the name … 

    • Avatar
      Charles Roddie

      You won’t need to migrate from .Net Core 3.0 to .Net 5. It will just be an update.

  • Morten Jonsen
    Morten Jonsen

    WCF over ASP.NET Core Web APIs – isn’t that MUCH slower than using NetTcpBinding?
    All new .Net applications should be using .Net Core 3? What about aspnet core for vb?
    .NET Framework 4.8 will be the last major version of .NET Framework.” I have way to large applications to port, so sad no new framework for those 🙁

  • Przemysław Wasylko
    Przemysław Wasylko

    Please consider porting WCF Server to .NET Core or at least parts of it (without all windows specific stuff with WS-I basic Profile 1.2 support). That would be much appreciated.

  • Avatar
    Raymond Tubbs

    What about Visual Basic.  I see no mention of it. Is it no longer included? 

      • Avatar
        Raymond Tubbs

        Thanks. I had looked and looked and somehow missed it. So it seems like I’m ok for a few more years…  I’ll be retired out before .net 5 is out dated…. hopefully….

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

    • Avatar
      Gavin Williams

      Funny, I see it oppositely to you, that .net standard and .net core have been a huge success.

  • Avatar
    Bill Loytty

    I agree with the need for WCF, and I will raise you System.Messaging (MSMQ). I am literally in planning meetings right now for a new application, and I would love to switch, but I have a metric buttload of legacy apps, all built on msmq.