.NET Core is the Future of .NET
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 Framework, ML.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 Framework, which 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.
What about ClickOnce? Will that be a supported distribution system for .NET 5 desktop applications?
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.
Speaking of which, do I notice that Google Chrome uses ClickOnce to install when installed via Internet Explorer?
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.
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.
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.
I second that.
Hi. When will MSIX be added to Windows 7?
And Windows 10 versions pre 1809?
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?
Why? Windows 7 goes EOL in January 2020.
That doesn’t mean anything. It will be still be used for many years to come.
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.
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
Or for applications that are providing such endpoints that thousands of clients are connecting to 🙂
i dont get the reasoning behind the refusal to move wcf forward.
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?
Reverse proxy is not required. Use the in-process hosting model. https://docs.microsoft.com/en-us/aspnet/core/host-and-deploy/aspnet-core-module
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.
Agreed. WCF is a must.
I think it’s definitely time to switch to WebAPI Core 2.
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.
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.
You can do RPC over named pipes with https://github.com/RandomEngy/PipeMethodCalls
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.
+1 – there needs to be proper migration scenario that allows us to keep compatibility with endpoints on the other end (both server and client)
In positive news, we just open sourced WCF. See https://devblogs.microsoft.com/dotnet/supporting-the-community-with-wf-and-wcf-oss-projects/ for more details.
Is there a replacement for WCF Web services? gRPC does not allow for Web browser clients to function directly.
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.
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.
Same here but microsoft refuses to listen or address this.
Well, what about C++/CLI?
As I can see they are working on this feature – https://github.com/dotnet/coreclr/issues/18013
what about a XAML standard that works cross platform? specially between xamarin.forms and uwp?
What’s the advantage?
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
Whats the migration strategy for WebForms? We have dozens of commercial applications – you have a WinForms a migration path.
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.
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.
Hmm, yea doubt thats going to work.
Same stategy for wcf. They want us to fck off or blow millions porting .
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.
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.
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.
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.