.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

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

  • Duc Thuan Nguy 0

    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 0

    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.

    • Daniel Sturm 0

      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?

    • Jon Miller 0

      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.

    • Daniel PlaistedMicrosoft employee 0

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

      • Wil Wilder Apaza Bustamante 0

        This comment has been deleted.

  • Olivier 0

    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?

    • Gavin Williams 0

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

      • Mike-E 0

        You’re not the only one who doesn’t get it.  UWP “management” has been struggling over what UWP is since its inception, and still is by the looks of it:
        https://www.zdnet.com/article/microsoft-wants-to-close-the-uwp-win32-divide-with-windows-apps/#
        This has been a full decade of failure in that division — “division” being the word that lives up to its meaning.  I’m amazed that any “manager” over there still has a job.

      • Charles Roddie 0

        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 0

      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 0

        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.

  • George Danila 0

    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 0

      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 0

    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 … 

    • Charles Roddie 0

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

  • Morten Jonsen 0

    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 0

    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.

  • Raymond Tubbs 0

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

    • Michel Renaud 0

      Last sentence of the fourth paragraph. 😉

      • Raymond Tubbs 0

        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 0

    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.

    • Gavin Williams 0

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

  • Bill Loytty 0

    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. 

    • Jason Nappi 0

      ditto.

Feedback usabilla icon