.NET Core 3.0 will reach End of Life on March 3, 2020
.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.
Light
Dark
18 comments
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?
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 handling, etc.
We release to production
It takes most of a year to do this production release. Since .net Core LTS version are supported for 3 years, we release 12 to 16 months after the .net Core LTS version is released.
It gives us less than 2 years until we need to start it all over again. Two years or less of production use before a forced upgrade because of .net Core LTS end of life is too short.
The 3 year LTS of .net Core forces us to release the large systems every 3 years or less and each of the large systems take 6 or more months to develop and release.
We have more than 5 large systems caught in this treadmill which means we do nothing but work on forced releases due to the short .net Core LTS lifespan.
These are financial systems, commodity trading systems which don’t get released often.
Financial records are required by law to be kept for 7 years.
Baseline take away is that from our CIO is if we spend $1+ million upgrading/enhancing a large core financial system, it should last for much longer than 2.5 years before being subjected to a forced upgrade by the vendor end of life-ing a .net Core LTS version.
Keeping those systems which are not yet on .net Core on the old .net Framework is not a solution, the old .net Framework will be supported for a long time, but, like prior products, will have fundamental fatal bugs which will not be fixed.
We’ve kept on SQL Server because it support major enterprise vesions for nearly 10 years and would not use it if it end of lifed every 3 years with a forced upgrade.
Our non-financial web sites get released more often, but that’s less than 24 percent of our work
It’s developing too fast!
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
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.
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.
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 any potential failures of your product.
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.
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.
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.
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 visual, modern ways of improving your devops options. These options give you the ability to test out preview SDK releases, pin your SDK to a specific version, or roll forward (or backward) when an automatic update is non-desirable. Kudu isn’t the only option.
And these aren’t external solutions; these are all options that are triggered by external forces (GitHub webhooks, for example), but that run well within the Azure fabric. Whereas Kudu is great for in-the-box, central-to-your-App-Service option, pipelines and actions give you a little more control.
All that said, we are working hard to ease the Kudu-deployment related pain this month by adding the 3.1 SDK to App Service.
I’ve asked this in several other places – when will UWP graduate to .netcore 3?