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