Searches for "framework dot net" and "dotnet framework" almost always come from the same problem: two things called .NET exist, they are not interchangeable, and documentation for both is everywhere. This article separates them cleanly: what .NET Framework is, what modern .NET is, and how to decide which one a given project should use.
What .NET Framework is
.NET Framework is the original .NET runtime. Microsoft released version 1.0 in 2002, and it became the foundation for a generation of Windows software. It includes a common language runtime (CLR), a large base class library, and the application models built on top: WinForms and WPF for desktop, ASP.NET Web Forms and later ASP.NET MVC for web, WCF for services, and ADO.NET and Entity Framework for data access.
Two facts define its limits today:
- It is Windows-only. It ships as a Windows component and has no supported Linux or macOS runtime.
- It is feature-frozen. Version 4.8 (and the 4.8.1 update on newer Windows versions) is the end of the line. Microsoft services it with security fixes for as long as the Windows versions it ships with are supported, but it receives no new runtime or language features.
That does not make it obsolete. It means it is in maintenance mode, exactly like classic ASP before it — safe to keep running, wrong to start new projects with.
What modern .NET is
Modern .NET began as .NET Core 1.0 in 2016: an open-source, cross-platform rewrite designed for servers, containers, and modern tooling. After .NET Core 3.1, Microsoft unified the naming — .NET 5 (2020), 6, 7, 8, 9, and .NET 10, with a new release every November. Even-numbered releases receive Long Term Support; odd-numbered releases get shorter support windows.
The easiest way to tell which platform a C# project uses is the target framework moniker in its .csproj file:
<-- .NET Framework project -->
<TargetFramework>net48</TargetFramework>
<-- Modern .NET project -->
<TargetFramework>net10.0</TargetFramework>
net48 means .NET Framework 4.8. net10.0 means modern .NET 10. The two can never be mixed inside one project — a compiled library targets one or the other — although a modern .NET process can call into .NET Framework code through COM or out-of-process boundaries.
.NET Framework vs modern .NET, side by side
- Operating systems: .NET Framework is Windows-only. Modern .NET runs on Windows, Linux, and macOS.
- Open source: .NET Framework is closed source. Modern .NET is developed in the open (
dotnet/runtime,dotnet/aspnetcore) under the MIT license. - Deployment: .NET Framework is installed once on the machine and shared by all applications; only one major version family can be present. Modern .NET supports side-by-side application-local runtimes and self-contained deployments.
- Containers: modern .NET has first-class, small container images. .NET Framework images are large Windows images and cannot run on Linux hosts.
- Language features: C# 7.3 is effectively the last language version fully supported on .NET Framework. .NET 10 ships C# 14, with years of improvements modern .NET applications can use.
- Performance: each modern .NET release brings measurable runtime and library gains. ASP.NET Core on .NET 10 is dramatically faster than ASP.NET on .NET Framework.
- Tooling: the modern
dotnetCLI, single-project files, andMicrosoft.NET.Sdk.Webreplace the older project system and build tooling.
What still runs on .NET Framework
Plenty of important software does, and that is fine:
- Enterprise line-of-business applications with years of business rules encoded in them.
- Windows desktop tools built with WinForms and WPF — note that both are fully supported on modern .NET as well.
- WCF services that still serve internal traffic.
- Web applications built with ASP.NET Web Forms or ASP.NET MVC on .NET Framework.
- Windows services and utilities that depend on Windows-only APIs or third-party libraries that never updated.
If a system is stable, well-tested, and meeting the business need, "it runs on .NET Framework" is not a defect. The question is only whether the platform is holding the business back.
When migrating makes sense — and when it does not
Migration is justified by business drivers, not by release years. Signals that a port is worth planning:
- You need Linux or container deployment for cost or platform reasons.
- You need performance improvements that only modern .NET provides.
- Third-party libraries you depend on have dropped .NET Framework support.
- Security or compliance requirements push you toward actively developed runtimes.
- You are already planning large feature work, so the rewrite cost can be shared with new value.
Signals that argue for waiting:
- Heavy dependence on Web Forms UI, which has no direct migration path — the screens must be rebuilt, and that should be a product decision, not a checkbox.
- Critical third-party components with no modern .NET equivalent.
- No test coverage, which turns a port into a rewrite with unknown regressions.
- No business driver at all — maintenance plus security patches is a legitimate strategy.
When you do migrate, the practical approaches are incremental rather than big-bang: use the .NET Upgrade Assistant and API compatibility analyzers to measure the work, port libraries bottom-up, run new features on modern .NET behind a reverse proxy while older screens stay put, and move screens feature by feature. Modern tooling, including AI coding assistants, helps most when the target structure is decided before the mechanical work begins.
Which one should you choose in 2026?
For anything new: modern .NET. It is where C#, ASP.NET Core, EF Core, and the entire tooling ecosystem invest. For existing applications: stay on .NET Framework unless one of the business drivers above applies. The two platforms coexist peacefully, and a modern ASP.NET Core service can even call into legacy .NET Framework components while the migration happens gradually.
Microsoft's official starting point is Microsoft Learn: .NET Framework documentation. To see what replaced it, continue with Part 3, Microsoft .NET Explained, or Part 4, ASP.NET Core Explained.
Key Takeaways
- .NET Framework is the Windows-only original .NET, frozen at 4.8/4.8.1 and serviced for security.
- Modern .NET (.NET 5 through .NET 10) is open source, cross-platform, and released yearly with LTS versions every other year.
- Check the
.csprojtarget framework:net48is .NET Framework,net10.0is modern .NET. - Migrate only for a business reason; modernize legacy screens at the product level, not as a mechanical port.
FAQ
Is .NET Framework still supported?
Yes, in maintenance mode. Microsoft provides security fixes for the .NET Framework versions that ship with supported Windows releases, but no new features.
Can .NET Framework run on Linux?
No. That is one of the main reasons modern .NET exists. If cross-platform support matters, the application must target modern .NET.
Is modern .NET faster than .NET Framework?
Yes, substantially, especially for web workloads. ASP.NET Core on modern .NET is a different, much faster stack than ASP.NET on .NET Framework.
Do I have to rewrite my application to move to modern .NET?
Not necessarily all at once. Libraries and services can often be ported incrementally, and legacy and modern components can run side by side while you move feature by feature. UI technologies such as Web Forms are the main exception — those screens must be rebuilt.
