.NET Core 3.0 will reach end of life on March 3, 2020. It is a “Current” release and is superseded by .NET Core 3.1, which was released on December 3, 2019. After that time, .NET Core patch updates will no longer include updated packages .NET Core 3.0. .NET Core 3.1 is a long-term supported (LTS) release (supported for at least 3 years). We recommend that you move any .NET Core 3.0 applications and environments to .NET Core 3.1 now. It’ll be an easy upgrade in most cases.
Upgrade to .NET Core 3.1
- Open the project file (the *.csproj, *.vbproj, or *.fsproj file).
- Change the target framework value from netcoreapp3.0 to netcoreapp3.1. The target framework is defined by the
<TargetFramework>or<TargetFrameworks>element. - For example, change
<TargetFramework>netcoreapp3.0</TargetFramework>to<TargetFramework>netcoreapp3.1</TargetFramework>.
Microsoft Support Policy
Microsoft has a published support policy for .NET Core. It includes policies for two release types: LTS and Current.
- LTS releases include features and components that have been stabilized, requiring few updates over a longer support release lifetime. These releases are a good choice for hosting applications that you do not intend to update often.
- Current releases include features and components that are new and may undergo future change based on feedback. These releases are a good choice for applications in active development, giving you access to the latest features and improvements. You need to upgrade to later .NET Core releases more often to stay in support.
Both types of releases receive critical fixes throughout their lifecycle, for security, reliability, or to add support for new operating system versions. You must stay up-to-date with the latest patches to qualify for support.
See .NET Core Supported OS Lifecycle Policy to learn about Windows, macOS and Linux versions that are supported for each .NET Core release.
I’ve asked this in several other places – when will UWP graduate to .netcore 3?
And yet Azure still can’t build a .NET 3.x solution – either 3.0 or 3.1 – due to SDK not rolled out still, despite 3.0 having been released on Sept 28th (a full 5 months ago): https://github.com/Azure/app-service-announcements-discussions/issues/129.
What is the ETA on being able to build .NET 3.x apps out of the box on Azure? (ie: Deployment Centre / Kudu)
you should be using Azure DevOps for Builds, and “Azure” for hosting, in which case you don’t need SDK in the hosting environment; just the runtime, which is there already
No we “SHOULDN’T” be using anything. Deployment Center in Azure is THE primary supported build path and core scenario for integrating repos to build and run on Azure.
If we wanted a pipelines solution we could go with GitHub/Bitbucket Pipelines or adopt DevOps, but these are are external solutions to what should be running out of box – as is fully advertised as such.
There is no excuse for this.
@Microsoft, how loudly do we need to scream about this? We need an official answer about this NOW.
https://github.com/Azure/app-service-announcements-discussions/issues/129#issuecomment-593999451
Trust us, we've heard. The .NET team is working with the App Service team to get the SDK out this month (March 2020). Yes, late, and for a multitude of reasons, none of which fun to explore but all of which are aimed at making sure existing customers aren't impacted by significant changes to the SDK.
As you mentioned, the Deployment Center in Azure is the place to go for your deployment options, of which Kudu, the original deployment engine for App Service, is supported. We also have Azure DevOps pipelines and a preview of GitHub actions, both which offer more...
I found an issue in 3.1. If i run ef command Script-Migration to generate sql script it wont work. I had to down my web api project to 3.0.
I wouldn’t mind the high version turnover if any of the versions were complete and at least matched the .net framework 4.x lineup for feature set.
This appears to just be a tactic of Microsoft to constantly not have to support anything properly.
.net core is basically a joke at this point and needs at least 5 years of stabilisation on a single version.
I believe the accelerated development cycle is a requirement to get Core in line with the 4.x feature set. I’m hoping they settle in to a longer support cycle and work on getting the bugs knocked out once Core is more feature complete. I agree that right now it’s a buggy mess and there is no way I would even attempt to migrate any of my .Net 4.X applications to Core yet.
Paul - I would caution you against such inflammatory phrases which both show your lack of understanding and you're immature exposure to these frameworks. The fact that somehow you missed the very clearly communicated expectations around these versions is not reflective of the product stability or the team that created it but on your quick to assess and slow to understand mind set. I would encourage you to spend more time understanding the stated availability and support of these frameworks and a line that with your work product instead of blaming your lack of understanding in these areas on...
and telling off customers proves what? posts that are honest should not be flamed on. i have over 25 years of dealing with software and i am also not liking some of what has been going on. if we cant speak our minds then why should we use the products ? when .net came out it was a great thing. today while it still has great stuff its also grown to a middle age of fragmentation, lack of clear vision and is getting to be more political than technical.
This short life of .NET Core releases is of great concern to ISVs such as us. How can we expect to put a long lived product in the field?
When c# winforms .net 3.1 came out I decided to port across a c# wpf app.
.net core 3.1 has double buffered graphics so is much quicker.
To start with .net 3.1 winforms was poor with all sorts of bugs.
So I reported the bugs one of which was forms designer crashing out.
They fixed the bugs which was great.
On the next release the forms designer crashing came back !
Yesterday they finally got it fixed ?(again.)
This bug was pretty fundamental to how the software works.
Clearly the software is being rushed out and bugs get added.
On one hand i get where you are coming from. But on the other hand, Microsoft explicitly explained lifecycle expectations in their 3.0 release announcement:
NET Core 3.0 is a ‘current’ release and will be superseded by .NET Core 3.1, targeted for November 2019. .NET Core 3.1 will be a long-term supported (LTS) release (supported for at least 3 years). We recommend that you adopt .NET Core 3.0 and then adopt 3.1. It’ll be very easy to upgrade.
Well clarified
It’s developing too fast!
From the blog it sounds like LTS releases (~3 year lifetime) was made specifically for that purpose. Do you require longer lifetime than that? They specifically mentions the differences between “current” releases (for example .Net Core 3.0) and LTS releases (for example .Net Core 3.1). That is how I understood it.
Short life of .NET Core LTS versions is also a large problem for us. We have many large .NET applications, some SOX regulated, some not.
For us to go through the much more stringent SOX required testing of one of the large applications:
We can only start development on a released version of .net Core due to our SOX auditors.
We take months producing the new version. Upgrading to the new .net Core version, fixing bugs/workarounds for .net core new version and adding business functionality
We do extensive testing over months
We get audited for SOX compliance, business risk, PII data...
Our non-financial web sites get released more often, but that’s less than 24 percent of our work