7/15/2021: this post was revised to update the support period for “Current” releases from 15 months to 18 months, or 6 months after the next release ships.
While we’ve covered .NET Core releases, cadence and support policies in previous blog posts, the information has been distributed across a couple of individual posts. With the .NET 5 release just around the corner, we thought this is a good time to bring all the information together into a single post as a refresher on these topics.
As we’ve covered previous posts, .NET Core releases have a very different model relative to .NET Framework so if you’re coming from .NET Framework application development and familiar with that, or just starting with .NET Core it is important to understand the release cadence, types, and support lifecycle for .NET Core so you can make the right choices for your situation.
Key Highlights
.NET Core ships major releases, minor releases, and servicing updates (patches). From a support perspective, there are 2 support “tracks” for .NET Core releases.
- The first track is “Current” releases – these .NET Core versions are supported for a period of 6 months after the next major or minor release ships.
- The second track is “Long Term Support” or LTS releases – these are supported for a minimum of 3 years, or 1 year after the next LTS release ships (whichever is longer).
.NET Core releases alternate between LTS and Current releases, so it is possible for an “LTS” release that shipped first (for example .NET Core 3.1) to be supported for longer than a “Current” release (for example .NET 5) that shipped later.
Servicing updates ship monthly for the most part and include both security and non-security (reliability, compatibility, and stability) fixes. .NET Core servicing releases are supported from the time they are released until the next servicing update is released. Servicing updates leverage runtime roll forward behavior, that is applications default to running on the latest installed runtime servicing update that is installed, so we take care to ensure a high degree of compatibility in servicing updates. When it comes to getting support for .NET Core, you have a choice between Microsoft assisted support and Community support based on your situation.
The rest of this post covers these areas in more detail:
- .NET Core Release Types – major releases, minor releases, servicing releases, and SDK feature bands
- .NET Core Lifecycle – modern lifecycle, Current releases, and Long Term Support (“LTS”) releases
- Getting support from Microsoft and the Community
- End of Support and Operating System support
- .NET Roadmap
.NET Core Release Types
.NET Core ships major releases, minor releases, and servicing updates (patches). Information about the release is encoded in the version associated with the release in the form of major.minor.patch.
For example,
- .NET Core 3.0 is a major release of the product.
- .NET Core 3.1 is the first minor release after the .NET Core 3.0 major release.
- .NET Core 3.1.17 has a major version of 3, minor version of 1 and patch update version of 17, that is, it’s the seventeenth patch for .NET Core 3.1.
Major releases
Major releases of .NET Core like .NET Core 2.0, 3.0 or .NET 5.0 generally include new features/functionality, new public surface area, and bug fixes. Due to the nature of the changes, these releases are expected to have breaking changes. All major releases install side by side with all previous major releases.
Minor releases
Minor releases of .NET Core like .NET Core 2.1 and 3.1 also include new features/functionality, public surface area, bug fixes, and may also have breaking changes. The difference between these and major releases is that the magnitude of the changes is generally smaller and therefore an application upgrading from .NET Core 3.0 to 3.1 has a smaller jump to move forward. Minor releases install side by side with all previous minor releases.
Servicing Updates
Servicing updates for .NET Core ship almost every month and these updates carry both security and non-security bug fixes. For example, .NET Core 3.1.8 is the eight update for .NET Core 3.1. When these updates include security fixes, they’re released on “patch Tuesday”, which is always the second Tuesday of the month and predictable. Servicing updates are expected to maintain compatibility and we take steps to ensure this. Starting with .NET Core 3.1, servicing updates are upgrades, that is, the latest servicing update for 3.1 will remove the previous 3.1 update upon successful installation.
Feature Bands (SDK only)
Versioning for the .NET Core SDK works slightly differently from the .NET Core runtime. .NET Core SDK updates sometimes includes new features or new versions of components like MSBuild and NuGet to align with new Visual Studio releases. These new features or components may be incompatible with the versions shipping in previous SDK updates for the same major/minor. Hence feature bands exist as a means of differentiating across such SDK updates.
The .NET Core SDK uses the concept of feature bands. For example, the first .NET Core 3.1 SDK was 3.1.100. This release corresponds to the 3.1.1xx “feature band”. Feature bands are defined in the hundreds groups in the third section of the version number. For example, 3.1.101 and 3.1.201 are versions in two different feature bands while 3.1.101 and 3.1.199 are in the same feature band. When .NET Core SDK 3.1.101 is installed, .NET Core SDK 3.1.100 will be removed from the machine if it exists. When .NET Core SDK 3.1.200 is installed on the same machine, .NET Core SDK 3.1.101 won’t be removed.
Runtime Roll-forward and Compatibility
Major and minor updates install side by side with previous versions and an application built to target a specific major/minor version continues to use that targeted runtime even if a newer version is installed, that is, the app does not automatically roll forward to use a newer major/minor version of the runtime unless you opt-in for this behavior. An application that was built to target .NET Core 3.0 will not automatically start running on .NET Core 3.1. In general, we recommend rebuilding the app and testing against a newer major or minor runtime version before deploying this to production. For more information, see Runtime Roll Forward.
Servicing updates are treated differently from major and minor releases. An application built to target .NET Core 3.1 targets the 3.1.0 runtime by default and automatically rolls forward to use a newer 3.1.1 runtime when that servicing update is installed unless you opt-out from this roll forward behavior. We default to this behavior because we want security fixes to be used as soon as they’re installed without any other action needed.
.NET Core Lifecycle
Fixed versus Modern lifecycle
The first thing to understand is that .NET Core adopts the modern lifecycle, which is very different from the traditional fixed lifecycle that has been used for .NET Framework releases. Products with fixed lifecycles like the .NET Framework as the name implies provide a fixed period of support, this is typically long, for example, 5 years of mainstream support (including security and non-security hotfixes) and another 5 years of extended support (security fixes only). Products like .NET Core that use a modern lifecycle typically adopt a more service-like support model that is shorter and ship more frequently.
From a support perspective, there are 2 flavors of support “tracks” for .NET Core major (and minor) releases. Each has its unique attributes and may be appropriate in different situations.
Current Releases
These .NET Core versions are supported for a period of 18 months, or 6 months after the next major or minor release ships (whichever is longer). Previously, Current releases like .NET Core 3.0 and 2.2 were supported for a period of 15 months, or 3 months after the next major or minor release shipped.
Example:
- .NET 5.0 shipped in November 2020 and is expected to be followed by .NET 6.0 in November 2021.
- .NET 5.0 support will end in May 2021 (that is, 6 months after 6.0, the successor to 5.0 ships)
Long Term Support (“LTS”) releases
These are supported for a minimum of 3 years, or 1 year after the next LTS release ships (whichever is longer).
Example:
- .NET Core 2.1 was released in May 2018 and was deemed an LTS release in August 2018, so it will be supported for 3 years (i.e. August 2021), or 1 year after the next LTS release, whichever is longer.
- The next LTS after 2.1 was 3.1 and this was released December 2019 (i.e. 1 year from this would be Dec 2020)
- Since August 2021 is later than Dec 2020 .NET Core 2.1 will be supported through August 2021.
It is possible for an older LTS release to be supported for longer than a newer Current release.
For example .NET Core 2.1 is an LTS release and will be supported through August 2021. .NET Core 3.0, which shipped later in September 2019, went out of support in December 2019.
Here’s a picture that shows the support lifecycle for various .NET Core releases. Note that this includes .NET 6.0 and releases in the future, so they’re for demonstrative purposes only. The specific lifecycle dates will be published at the time the releases ship.
If you’re building a service and expect to continue updating it on a regular basis, then a .NET Core “Current” release like .NET 5.0 may be your best option to stay up to date with the latest features .NET Core has to offer.
On the other hand, if you’re building a client application that will be distributed to consumers and this application needs to be supported for a certain period before the consumer can be reasonably expected to upgrade to the next version of this application, then picking an LTS release like .NET Core 3.1 or .NET 6.0 might be the right option.
Servicing releases
.NET servicing releases are supported from the time they are released until the next servicing update is released. The release cadence is typically monthly. This means you need to regularly install servicing releases to ensure that your apps are in a secure and supported state.
For example, if the latest servicing release for .NET Core 3.1 is 3.1.17 and we ship 3.1.18, then 3.1.17 is no longer the latest and the supported servicing level for 3.1 is 3.1.18.
More information about the latest shipped servicing updates for all supported versions of .NET Core can be found on the .NET Core Downloads page.
Getting Support
Microsoft Support
For assisted support with .NET Core technologies, contact a Microsoft Support Professional.
You need to be on a supported servicing level (the latest available servicing update) to be eligible for support. If a system is running 3.1 and the 3.1.17 servicing update has been released, then 3.1.17 needs to be installed as a first step.
Community Support
Community support is another great way to get help and even contribute to projects. See our Community page for details.
.NET Core versions and support
Here’s a snapshot of the end of support date for the various versions of .NET Core. For the most current information you can refer to the .NET Core support policy page.
| Version | Original Release Date | Latest Patch Version | Patch Release Date | Support Level | End of Support |
|---|---|---|---|---|---|
| .NET 5.0 | November 10, 2020 | 5.0.8 | July 13, 2021 | Current | May 2022 |
| .NET Core 3.1 | December 3, 2019 | 3.1.17 | July 13, 2021 | LTS | December 3, 2022 |
| .NET Core 3.0 | September 23, 2019 | 3.0.3 | February 18, 2020 | EOL | March 3, 2020 |
| .NET Core 2.2 | December 4, 2018 | 2.2.8 | November 19, 2019 | EOL | December 23, 2019 |
| .NET Core 2.1 | May 30, 2018 | 2.1.28 | May 11, 2021 | LTS | August 21, 2021 |
| .NET Core 2.0 | August 14, 2017 | 2.0.9 | July 10, 2018 | EOL | October 1, 2018 |
| .NET Core 1.1 | November 16, 2016 | 1.1.13 | May 14, 2019 | EOL | June 27 2019 |
| .NET Core 1.0 | June 27, 2016 | 1.0.16 | May 14, 2019 | EOL | June 27 2019 |
End of support
End of support refers to the date after which Microsoft no longer provides fixes, updates, or technical assistance for a particular product version. As this date nears, make sure you have moved to using a supported version and have the latest servicing update installed. If you continue to use a version that is out of support, you’ll no longer receive security updates that will be required to protect your applications and data.
.NET Core support and Operating Systems
.NET Core can be run on a range of operating systems. Each of these operating systems has a lifecycle defined by its sponsor organization (for example, Microsoft, Red Hat, or Apple). The .NET Core team applies each of those lifecycle schedules to inform adding and removing support for operating system versions.
When an operating system version goes out of support, we stop testing that version and providing support for that version. Users need to move forward to a supported operating system version to get support.
.NET Roadmap
.NET Core is where new investments in .NET are happening. New applications that want to take advantage of the new features in .NET should consider moving to .NET Core.
Here’s our planned release cadence for .NET Core.
We will ship .NET Core major releases every year, with every alternate release designated as a Long Term Support (“LTS”) release. .NET Core 3.1 is an LTS release and the next one will be .NET 6.0, shipping around November 2021. The one after that will be .NET 8.0 shipping November 2023, and so on. A relevant point worth calling out is that .NET 5.0 is not an LTS release.
.NET Framework
As we’ve covered in previous blog posts, .NET Framework 4.8 was the last major release of the .NET Framework. If you have existing .NET Framework applications that you’re maintaining, there is no need to move these applications to .NET Core. We’ll continue to support and service .NET Framework for bug fixes – reliability and security fixes. .NET 4.8 continues to ship with Windows and will be supported with new releases of Windows. For compatibility reasons, there are no plans to remove .NET Framework 4.8 from Windows.
Summary
If you’re using an out of support .NET Core runtime like 1.x, 2.0, 2.2, or 3.0, we strongly recommend you update your application to a supported version like 5.0, so you can benefit from the security updates and other non-security fixes we ship in our monthly updates.
See our blog post on the .NET 6.0 Preview 6 release for the latest bits and to give this a spin.
As usual Microsoft cant be bothered to answer anyone’s questions : – )
Can you clarify in Visual Studio, how does the interaction between the installed SDK and the project linked NuGet Packages work?
When a new servicing release becomes available, NuGet offers it at the project level (and can even install only some libs from it). Alternatively I can install it system wide, and VS will pick that up.
a) Why offer to update it at project level, since servicing version is effecitvely ignored once deployed anyway?
b)...
As usual Microsoft cant be bothered to answer anyone’s questions : – )
Hello Microsoft.
Looking forward to .NET 5.0 but we also need to know how to block the installation on those application servers where its not supported.
Is the registry key to block it, “BlockNetFrameWork50” and set the value to “1” ?
What about packages like Microsoft.Extensions.* ? They seem to be versioned in the same way as the runtime and in-box frameworks like ASP.NET Core, including servicing updates. But it's not clear whether I need to update these packages every time a servicing version of them is released, to catch up all security and bug fixes. I suppose I should treat these packages like any other third party libraries, but they look like part of .Net...
Hi,
Can you please explain why .net team want .net core version to grow,
Why we need to increases this quickly.
What the problem with something like the following
V5 current – just because its the first version
V5.1 current
V5.2 current
V6 LTS
V6.1 current
V6.2 current
V7 LTS
V8 LTS
V9 LTS
Thanks
Call LTS (Long Term Support) long, for 3 years only, is like a joke for me. In the near future products with so tiny support will not survive in the spacial era.
About “For compatibility reasons, there are no plans to remove .NET Framework 4.8 from Windows.” it’s ok until they change completely Windows for a new MASTER BLASTER WIN SOMETHING that will not run .NET Framework 4.8 anymore.
jefferson2020
Any chance to see in the future to see a free reporting tool like RDLC inside dot net?
I have a few projects at work that use postgresql db, and nobody will pay a 700 $ library for reporting, and I need to to graphs too in the report. ( Fast report free library doesn’t do graphs )
You, me and many more want to have an updated RDLC tool, and ASP.Net Core report viewer.
I think the Microsoft reporting team that worked on .Net viewers is basically gone. You don't see anyone at Microsoft talk about it anymore. There's a now 3-year old article where Microsoft says they are acquiring another company's tool, to use as a web viewer, but the article is now 3 years old.
For anything "reporting", all they talk...
Heh, I’ll think I’ll write something in php or scala/java , since there there’s something. Like jasper reports.
Ps : PowerBi is really expensive especially the premium tier where you can install on premise and have the classic reports. I mean : PowerBi is useless when you don’t have to do Business intelligence.
I mean 5000 dollars per month or sql server enterprise.
In light of how the roadmaps of .Net5 and WinUI3, when will we be able to use win2d in Desktop apps?
Win2D should already work with .NET Core 3.1.
https://github.com/Microsoft/Win2D
What about winforms application that run on win7 and win8. For win10 we at our organization are using UWP and its awesome to work around. With more and more third party tools developed for .net core its getting easier and most of my favourite tools are already on .net core. But what about those old applications, we develop ERP and CRM that requires regular updates and bug fixes as on now with .net we just...
Windows 7 has already ended its extended support in January 2020, whereas Windows 8.1 will see the same in January 2023, as you can see in this Microsoft website: https://docs.microsoft.com/en-us/dotnet/core/install/windows?tabs=netcore31
You may want to stick with .NET Framework 4.8 on those platforms to continue using Windows Forms and WPF for your ERP and CRM apps. I think there is some support for WinForms and WPF in .NET Core 3.1 which was supported on Windows 7...
.NET Core 3.1 LTS already supports WinForms (designer is in preview and is near to completion) and WPF (designer is completed) application on Windows 7 and Windows 8.1.
Upcoming .NET 5.0 will also support Windows 7 and Windows 8.1, don't mislead. And it will obviously have WinForms and WPF application support.
Unlikely that .NET 6.0 (November 2021) will support Windows 7, but still support Windows 8.1 (EOL January 2023).
I talked about Windows 7 and Windows 8.1 support, not about .NET Core support on those two platforms, I’m sorry if my statement was confusing. You’re correct, .NET 5.0 will support Windows 7. In general, it is better for users to migrate to a supported OS, that is, Windows 8.1 or Windows 10.