NET Core Releases and Support
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.
Light
Dark
43 comments
Is .NET 5.0 not being released, or is it more a small update?
.NET 5.0 falls under the “Major release” bucket and will include many new features and fixes. We have shipped multiple previews of .NET 5.0 this year and recently shipped RC1. See the .NET 5 RC1 blog post for more info.
An application that was built to target .NET Core 3.0 will not automatically start running on .NET Core 3.1.
But Runtime Roll Forward tells that
One of the following values must be specified. If the setting is omitted, Minor is the default. (Roll forward to the lowest higher minor version, if requested minor version is missing. If the requested minor version is present, then the LatestPatch policy is used.)
Which one is right?
It’s somewhat subtle. Imagine a machine with .NET Core 3.0 installed and a .NET Core 3.0 app that uses it. If you install .NET Core 3.1, the 3.0 app will continue using 3.0. On the other hand, if you run a 3.0 app on a machine with only .NET Core 3.1 present, the app will run on .NET Core 3.1. The app will not roll-forward to 5.0, even if .NET 5.0 is the only version present.
In short, apps will roll forward to a later minor version (for the targeted major version) of .NET if the “built with” version is not present. We added this behavior to account for the pattern of 2.0 and 3.0 where 2.1 and 3.1 were more minor updates, and we were confident about compatibility. If you built an app for 3.0, we didn’t want to force people to recompile the app for 3.1 just to get it to run on a 3.1-only machine.
Looking forward, We don’t have any plans for a 5.1 or a 6.1 (at least not yet) so this aspect of .NET activation behavior may end up being the subject of trivia in the long term.
Will .NET 5 or future versions of .NET (Core) ever be bundled with Windows like .NET Framework is?
I also would like to know that will .NET 6, 8, .. be bundled with Windows?
Otherwise all app need to include used parts of the .NET.
It would be nice if we can freely decide that if we want to:
1.) Bundle a concrete version of .NET with the app
2.) Not bundle, but specify that we want to use a specific version
3.) Not bundle, but specify that we want to use the lates version
Bundling .NET Core with Windows is not something we’re considering at this time. Customers that have a strong need for ensuring the runtime is pre-installed on Windows can continue to use the .NET Framework which ships as a component of Windows. We will continue to support and service the .NET Framework for as long as it continues to ship in Windows.
The other part of your question related to using a specific version (or the latest) is covered by existing documentation:
https://docs.microsoft.com/en-us/dotnet/core/versions/selection
Are you serious? If new versions will not be shipped as Windows update, folk will just stuck with .Net Framework 4 forever. And how are you going to publish security updates for .Net 5 / 6 / 7? This would be security disaster for thoose who will switch to new .Net.
This is very disappointing news. In fact, without support from Windows side, .Net 5 will be just yet another “.Net for Linux” like .Net Core was.
As far as I know .NET Core 3.1 and upcoming .NET 5 is planned to be updated via Microsoft Updates channels. See https://github.com/dotnet/core/issues/1541 and following https://github.com/dotnet/core/issues/5013
We’re conflating a few different concepts here, let me try to clarify. Firstly, Windows Update (WU) is for Windows components, while Microsoft Update (MU) is for updating any Microsoft product. All Windows machines get updates via Windows Update (WU), but getting updates for other Microsoft products like Visual Studio or SQL requires opting in to Microsoft Update (MU). We have no plans of making .NET Core a component of Windows, therefore updates for .NET Core will not be offered on WU, but we are working on a plan to make updates for Core available via MU in the future.
Also to reiterate, .NET 5 is not an update for the .NET Framework family that is .NET 4.8, instead it is the next release after .NET Core 3.1 – this is an update for the Core family. .NET 4.8 was the last update for the .NET Framework line, going forward we will only ship new versions for the .NET Core side of the house. We will continue to support and service .NET Framework for security, reliability and compat fixes of course, but new features and functionality will be available on .NET Core. The next release in the line of .NET Core releases will be .NET 5.
When is MS going to realize that a modern release cycle doesn’t work for Windows. This isn’t a 2 year Android or iOS device. Windows is installed in enterprises that can take a year or more to get installed across the entire system. Updating a single app that relies on .NET (or any language) can take 6 or more months either because it is a third party app that requires consultants or service partners to update or simply because there are so many apps to update.
Trying to force companies to update frameworks just so they are “modern” isn’t a rationale, it is an excuse. The end result is going to be the same. We will not be updating frameworks just because MS has deemed them EOL. We will either stop using .NET altogether for our apps (because C++ doesn’t have any of these restrictions) or we’ll stop targeting any version that isn’t LTS and therefore skipping whole versions of .NET. This really isn’t rocket science. At some point MS needs to realize that this “mobile” mindset doesn’t work for an enterprise OS like Windows. MS really needs to rethink their support strategy or the exodus from .NET (or the lack of migrating to it at all) is going to be high.
Maybe it’s time to change your corporate mindset? Every industry is embracing agile, large cumbersome code bases and unmaintainable enterprise apps are on the way out. I’m glad Microsoft is pushing ahead with an aggressive schedule.
Was this type of response really called for? This type of “experience gatekeeping” isn’t really useful. You don’t have to have 30 years of maintaining mainframe cobol code to see the writing on the wall. Enterprise is becoming less about waterfall coding by third party vendors that are immediately out of date. We work with our customers and stakeholders daily, we can push out weekly or even daily builds to production. We can’t expect Microsoft to put their key platforms on hold just because some industries refuse to catch up.
“Every industry” Is not at all true. We still have customers running our industrial application on Win2K and VB6 based software.
We offer an LTS support cycle because it’s needed, as you described. If the shorter release cycles don’t work for you, that’s OK. Choice!
As Justin and Richard said previously, you hace choice. If your company doesn’t want to respond in an agile way and want something fixed, stick with .NET Framework 4.8, C# 7 and Windows 10 Enterprise LTSC. .NET Core, with .NET 5 and .NET 6, offers what businesses that embraced agile wants: more innovative features, more bug fixes and more performance, being cross-platform as well. You have choice.
At some point there will be unix compatibility? in my case we work with unix servers.
.net core already runs natively on Linux
You must have misread. He said UNIX, not Linux.
Where can I download Unix? /s
Indeed.
We support multiple variants of Linux. There has been efforts to support FreeBSD, but that was never completed. We don’t support Solaris, for example.
here, for example 😉
Ramon, we’re constantly evaluating our support for the various distros/variants, can you share what distro you’re using?
Thanks for the great info.
My one gripe is that this doesn’t follow semantic versioning. I typically expect that minor version updates won’t break things. I’ll need to remember that the .Net versioning is a snowflake.
Hopefully that won’t be case by the time .NET 6 ships. If everything goes as the plan says, it shouldn’t be a problem as far as I can see.
How long is Visual Studio going to support .NET Framework 4.8? Or, you get stuck on an old version of Visual Studio?
Jon, there are no plans to change (remove) Visual Studio support for the .NET Framework 4.8 at this time.
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 replace a dll file and our work is done, but will it be possible in .net core.
Thanks a bunch.
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 and 8.1, so you can try that but you would be stuck in .NET Core 3.1. I would suggest to migrate your clients to Windows 10 as soon as they can.
.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.
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
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 about now is Power BI.
Microsoft says they care about small businesses and independent developers who use Visual Studio (to have the tools they need), but that’s not true for reporting.
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.