NET Core Releases and Support

Jamshed Damkewala

Jamshed

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

.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.7 has a major version of 3, minor version of 1 and patch update version of 7, that is, it’s the seventh 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 3 months after the next major or minor release ships.

Example:

  • .NET Core 3.0 shipped in September 2019 and was followed by .NET Core 3.1 in December 2019.
  • .NET Core 3.0 support ended in March 2020 (that is, 3 months after 3.1, the successor to 3.0 shipped)

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

.NET Core Lifecycle

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.8 and we ship 3.1.9, then 3.1.8 is no longer the latest and the supported servicing level for 3.1 is 3.1.9.

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.8 servicing update has been released, then 3.1.8 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.

VersionOriginal Release DateLatest Patch VersionPatch Release DateSupport LevelEnd of Support
.NET Core 3.1December 3, 20193.1.8September 8, 2020LTSDecember 3, 2022
.NET Core 3.0September 23, 20193.0.3February 18, 2020EOLMarch 3, 2020
.NET Core 2.2December 4, 20182.2.8November 19, 2019EOLDecember 23, 2019
.NET Core 2.1May 30, 20182.1.22September 8, 2020LTSAugust 21, 2021
.NET Core 2.0August 14, 20172.0.9July 10, 2018EOLOctober 1, 2018
.NET Core 1.1November 16, 20161.1.13May 14, 2019EOLJune 27 2019
.NET Core 1.0June 27, 20161.0.16May 14, 2019EOLJune 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.

.NET Core Release Roadmap

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 3.1, 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 5.0 RC1 release for the latest bits and to give this a spin.

 

45 comments

Leave a comment

  • Avatar
    Alexey Leonovich

    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?

    • Avatar
      Richard LanderMicrosoft employee

      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.

    • Avatar
      devtommy

      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

    • Jamshed Damkewala
      Jamshed DamkewalaMicrosoft employee

      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

      • Avatar
        Oleg Mikhailov

        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.

        • Jamshed Damkewala
          Jamshed DamkewalaMicrosoft employee

          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.

  • Avatar
    Michael Taylor

    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.

    • Justin Stigall
      Justin Stigall

      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.

      • Justin Stigall
        Justin Stigall

        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.

    • Avatar
      Jorge Morales Vidal

      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.

  • Avatar
    Daniel Schroeder

    Thanks for the great info.

    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.

    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.

  • Avatar
    Damir Tulepov
    1. What about nuget packages – many of them have same versioning schema 2.1.x/2.2.x/3.0.x/3.1.x ? For example after update from 2.1 to 2.2 we need update nuget packages (ASP.NET Core/Logging etc), but because 2.2 is not LTS after EOL we roll backed to 2.1 and some nuget packages have different api/functionality between 2.1.x/2.2.x. If any security vulnerability will found in nuget packages from MS fixes will be backported and packages will be updated with same semver (.net core major.minor.package_version) ?
    2. And what about self contained deployment and security fixes ? Can self contained app use latest installed patch if globally installed .NET Core version have patch version greater than self contained ?
    3. .NET Framework 4.8 will have only .net standard 2.0 ? If we plan consume some library from old full .NET Framework (4.8.x) we must add multitargetting with .net standard 2.0 and never use new api (or use #if directives) ?
      Recently found that .net 4.8 and .net standard 2.1 not compatible – method not found in String.Split(String, StringSplitOptions) in runtime (used my .net standard 2.1 library from Linqpad 5).
    • Avatar
      Jorge Morales Vidal

      1) If you need to support .NET Core 2.1 and .NET Core 2.2, you can use .NET Standard 2.0 to support those .NET Core versions in your NuGet packages, check the .NET Standard support table. You can also support multitargeting in your csproj, specifying what target frameworks your library supports, and using preprocessor directives in your code to use specific API from those .NET versions.
      2) Self contained applications bundles the .NET Core runtime with the app, so it can’t use any globally installed .NET Core version present in the machine. If you want to use the latest patch version, you would have to publish and deploy your app again.
      3) As mentioned in this article, there are no plans to update .NET Framework 4.8 to support .NET Standard 2.1, so yes, your NuGet library would have to use preprocesor directives (#if) when targeting .NET Standard 2.0, and others when targeting .NET Standard 2.1, etc.

    • Avatar
      Richard LanderMicrosoft employee

      For ASP.NET Core NuGet packages, we switched to a new scheme (I think with 3.0) where you don’t have to add PackageReferences for ASP.NET Core in most cases. It is for the reason that you say. If you build your app with a new SDK, and it doesn’t have any ASP.NET Core package references, you are good. You may need to create a new 3.1 or 5.0 project to see the new approach.

      We briefly considered “upgrading” a self-contained app to use the globally installed framework for security. It’s a strange scenario. If you are willing to use the global runtime to service your self-contained app, then you might as well start with a framework dependent app in the first place. I consider this a very niche scenario.

      Your understanding of .NET Framework 4.8 and .NET Standard is correct. We are not adding new APIs to .NET Framework, so it will never be compatible with .NET Standard 2.1.

  • Avatar
    Sohil Ahmed

    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.

    • Avatar
      Jorge Morales Vidal

      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.

      • Avatar
        Alexey Leonovich

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

        • Avatar
          Jorge Morales Vidal

          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.