Released in 2002, .NET Framework introduced the world to the C# language and came to be a stable, productive foundation for many Windows-based applications, including web sites through the ASP.NET framework. A new cross-platform version of .NET (originally called .NET Core, and now just .NET) was released in 2016, which saw the lion’s share of investment from Microsoft. .NET Framework had its last major release in 2019 (version 4.8), with 4.8.1 coming in 2022. Knowing the level of attention given to the newer cross-platform .NET, why would teams in 2025 choose to start new projects using .NET Framework instead of using the newest platforms and libraries?
Stability
The newer cross-platform .NET runtime has predictable yearly releases as well as a fixed support policy. Odd-numbered releases receive Standard Term Support (STS) for 1½ years, while even-numbered releases receive Long Term Support (LTS) for 3 years. In November 2024, .NET 9 was released and it will be supported until May 2026, while .NET 8 was released in November 2023 and will be supported until November 2026.
In contrast, the support policy for .NET Framework is more open-ended. Since .NET Framework is a Windows component, it is supported for as long as it continues to be shipped along with Windows. There has been no indication that there are plans to remove .NET Framework (in fact, the support policy states, “.NET Framework 4.8.1… will continue to be distributed with future releases of Windows”), so while the nominal end of mainstream support for .NET Framework 4.8.1 is October 2029 (5 years from the release of Windows Server 2025), it is expected that it will continue to extend as new versions of Windows are released.
When developing solutions on .NET Framework, you can expect many years of support without any effort from your development team. Any security issues will be silently patched by running Windows Update, even if the developers forget all about the application or the source code is lost. Of course, it’s not a bad idea to plan regular reviews of the inventory of applications your company oversees, but it’s good to know that the effort required to sustain the status quo will be minimal.
Applications built upon the newer .NET will require attention at minimum every three years, if everything is planned to prioritize stability. If there’s a need or desire to use a non-LTS release the stability window shrinks drastically. Ideally, this is a forcing factor to encourage investment and improvement, but in many cases it will leave companies unknowingly using unsupported and potentially vulnerable applications.
Tooling and Libraries
One of the major reasons to decide to build solutions with the newer .NET is to get access to the latest tools and libraries. However, a lesser known “secret” is that many of the tools and libraries for newer versions of .NET continue to work with .NET Framework. For example, less than half of new C# features require runtime support, so they can be used so long as you have the newer toolchain installed (e.g. the latest version of Visual Studio) and configure your project to use the newer C# version. This includes collection expressions and primary constructors from C# 12 as well as source generators, records, raw string literals, using declarations and switch expressions. And most of the other features just require the existence of a particular type, which can be provided by packages like Polyfill or PolySharp. Likewise, the simpler SDK-style projects are available so long as you don’t need specific WebForms functionality.
About half of the NuGet libraries that Microsoft publishes to support ASP.NET Core and the .NET Generic Host are targeting .NET Standard 2.0, which means that they support .NET Framework 4.7.2 and later, in addition to newer .NET. The most prominent package that doesn’t support .NET Framework is Entity Framework Core (after version 3), however Entity Framework 6 (not Core) is still supported (on both .NET Framework and cross-platform .NET) and offers a very similar experience.
Conclusion
The newer cross-platform .NET offers many benefits to developers, including a focus on performance and supporting the newest paradigms. However, its support policy can leave companies unprotected shortly after an initial investment if careful planning isn’t in place. In contrast, .NET Framework has a much stronger level of support (in part because of its lack of active innovation) and is still a totally valid platform to build upon. Many of the benefits of the newer platform are still available in one way or another for projects which choose .NET Framework for its stability.