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

Scott Hunter [MSFT]
Scott Hunter

Director Program Management, .NET

Follow Scott   

Nerk 2019-05-06 15:40:59
What about ClickOnce? Will that be a supported distribution system for .NET 5 desktop applications?
Drew Freyling
Drew Freyling 2019-05-06 16:51:32
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
Sam Covington
Sam Covington 2019-05-06 18:12:04
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 2019-05-06 19:22:45
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.
Fabion Burke 2019-05-06 20:00:59
Is there a replacement for WCF Web services? gRPC does not allow for Web browser clients to function directly. 
John Fedak 2019-05-06 20:46:13
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.
Kexy Biscuit 2019-05-06 22:36:08
Well, what about C++/CLI?
emiliano84 2019-05-06 22:47:37
what about a XAML standard that works cross platform? specially between xamarin.forms and uwp?
Matthew Hughes 2019-05-06 23:11:01
Whats the migration strategy for WebForms? We have dozens of commercial applications - you have a WinForms a migration path.
Johan Appelgren 2019-05-06 23:12:25
Are there any plans for handling COM based addins using .NET Core? For Office COM addins for example. According to https://github.com/dotnet/core-setup/blob/master/Documentation/design-docs/COM-activation.md#compatibility-concerns it sounds like it won't work if there are multiple addins that do not use the same version of .NET Core. 
Duc Thuan Nguy 2019-05-06 23:52:42
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 2019-05-07 00:37:43
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.
Olivier 2019-05-07 01:16:14
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?
George Danila 2019-05-07 01:55:38
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.
Neil Walker
Neil Walker 2019-05-07 01:59:35
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 ... 
Morten Jonsen
Morten Jonsen 2019-05-07 02:19:51
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 2019-05-07 04:06:32
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 2019-05-07 04:36:54
What about Visual Basic.  I see no mention of it. Is it no longer included? 
Hugo Ferreira
Hugo Ferreira 2019-05-07 06:54:52
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.
Bill Loytty 2019-05-07 08:56:04
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. 
David Hunter 2019-05-07 09:09:35
Any news on allowing C++/CLI to target .NET Core. Hopefully your not going to leave all of us hanging given that there is no viable alternative to C++/CLI for calling native C++ from .NET ( please don't suggest PInvoke! )
Greg Sohl 2019-05-07 10:26:25
My previous comments were feature specific. But I should have started with - Thank You! Getting us back to one framework is where we need to be. The general direction is right. Now, how to avoid leaving the important pieces behind just because they aren't in the news anymore. The reason for that - they just work, and need to continue to.
Jon Miller 2019-05-07 12:44:14

Thanks for throwing Web Forms developers under the bus and recommending Blazor as a replacement. Something that is basically only experimental at this point. Time will tell whether it is another Silverlight. Stupid move not supporting Web Forms when you support Windows Forms and WPF.

Tom McDerp
Tom McDerp 2019-05-07 16:51:57
“If you are a remoting or WCF developer and want to build a new application on .NET Core, we would recommend either ASP.NET Core Web APIs or gRPC (Google RPC,” Then you have failed to listen to your customers. I adivse you to go f yourself. Because that is what you are telling partners and enterprise customers with millions of dollars invested in wcf. The backlash will cost Microsoft with this attitude and abandonment.
Zachary Parton
Zachary Parton 2019-05-08 06:42:04
Got my torch and pitchfork to join in with the WCF folks. Give us the code if you don't want it anymore.
christos karras 2019-05-08 07:21:47
This means we need a migration plan for any .Net Framework feature and library that won't be ported to .Net Core. There should be a centralized document (on docs.microsoft.com and/or github) listing .Net Framework features/libraries and their status for .Net Core: Statuses: - Already available, without breaking changes - Alternative available, but there are breaking changes (Name the alternative and reference a document for migration guidance) - Planned for .Net Core 3.x - Won't be available Just a few examples I can quickly think of: - WCF - ASP.Net WebForms - GAC - Entity Framework 6 - Owin - Asp.Net MVC - Asp.Net Web Api - COM Interop - Windows Forms Yes I know some of these are/will be available but I know it from searching on forums, UserVoice, etc, not from any cannonical source. There needs to be an official centralized exhaustive list with all this information, so that we can start planning and refactoring affected apps. Also, if there are too many unsupported features/libraries on .Net Core, it may be implausible to migrate legacy apps to .Net Core, so it's more likely these applications will get stuck on .Net Framework 4.8 and Microsoft will need to keep supporting .Net Framework 4.8 for decades, until all these legacy applications have been rewritten (if that ever happens)
Mottor Demottor 2019-05-08 07:51:42
Make ONE Exe for console applications possible. I do not want to hear questions like: "Why are you deliver 50 DLLs? Java has only one jar." Isn't possible to remove all unused code from all DLLs and make one exe?
Kyle Brown 2019-05-08 08:12:05
For people talking about WCF and WebForms support in .NET Core "Existing applications are safe to remain on .NET Framework which will be supported."
SuperCocoLoco . 2019-05-10 02:35:21
Without Visual Basic in ASP.NET Core or in Blazor is imposible to migrate to .NET Core or .NET 5. I know C# but i prefer Visual Basic to code, more clear code and more readable and if i want to use a C-Style language i use C++, Javascript, etc. But for .NET I refuse to code in C#. I don't like it and I will never use it.
sballard@netreach.com 2019-05-10 10:16:14
Does this mean that Web Forms code won't be able to run on .NET 5? If not - I'm not sure what the licensing situation is for the .NET Framework source code, but is there any prospect of a community project to get the Web Forms code running within v5 if MS isn't going to do it officially?
anonymous 2019-05-12 02:27:51
This comment has been deleted.
Nick K 2019-05-14 16:40:41
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 2019-05-14 17:57:15
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 2019-05-15 00:43:02
What about C++ ?  Thank you
Ken Domino 2019-05-15 06:00:46
What is the future of Net Standard? I was planning to rely on its existence for my compiler and framework for the GPU.
Mark Magagna
Mark Magagna 2019-05-15 07:44:55
How does this announcement square with https://devblogs.microsoft.com/dotnet/introducing-net-5/?utm_source=vs_developer_news&utm_medium=referral.One says .NET Core 3 is the future, the other says .NET 5 is.
Michael Taylor 2019-05-16 07:37:44
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 2019-05-20 18:25:30
What, still no Code Contracts?
selvakumar palanisamy
selvakumar palanisamy 2019-05-21 02:51:33
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/>