People still say ".NET Core" for a project that is net8.0 or net10.0. The interview answer is the naming, then the support date. The project answer is the TargetFramework.
Hub: Architecture. Broader question bank: .NET interview questions.
Real-world analogy
.NET Framework is a house that only exists on one street. The street is Windows. .NET Core was the same family building houses on other streets, and they used a different family name so nobody mixed up the keys. From .NET 5 onward they dropped the extra name. People still say "Core" the way a town keeps an old street sign. The sign is not the address. The address is the TargetFramework in the project file.
Worked example
A contract says ".NET Core 8." The csproj says net8.0. There is no product called .NET Core 8. The runtime that gets security fixes is .NET 8, and Microsoft's support policy ends that on November 10, 2026, the same day as .NET 9. A new API in this repo's shape targets net10.0, which is the current long-term release through November 14, 2028. Leaving netcoreapp3.1 in an old project is not a style choice. That runtime left support in December 2022, and no one is patching it.
The three names
| Name you see | What it actually is | New app? |
|---|---|---|
| .NET Framework 4.x | Windows component. ASP.NET MVC and Web API on System.Web. Last major is 4.8. | No |
| .NET Core 1.x, 2.x, 3.1 | Cross-platform rewrite. The brand stopped here. 3.1 left support in December 2022. | No |
| .NET 5 and later | Same line as .NET Core, without the word Core. Current long-term release is .NET 10. | Yes |
.NET 5 was the rename, not a new product from scratch. If a job post says ".NET Core" and the file says net8.0, they mean this line.
What is still patched
Dates below are from Microsoft's support policy, checked September 18, 2026. Confirm them on the .NET support policy (opens in a new tab) and the lifecycle table (opens in a new tab) before you pin a runtime. Microsoft also published the November cutoff on the .NET blog (opens in a new tab).
| Version | Kind | End of support |
|---|---|---|
| .NET 6 | Old LTS | November 2024. No patches. |
| .NET 8 | LTS, maintenance | November 10, 2026 |
| .NET 9 | Standard term, maintenance | November 10, 2026 |
| .NET 10 | LTS, active | November 14, 2028 |
.NET Framework 4.8 is not a row on that table. It follows the Windows release it ships with. That is not a reason to start an API on it. ASP.NET Core does not run on Framework.
A project on net8.0 still runs after November 10, 2026. It just stops receiving fixes. That is the risk, not a compiler error on the morning after.
What to put in the csproj
<TargetFramework>net10.0</TargetFramework>
Use net8.0 only when Azure App Service, a customer image, or a library you cannot replace is still on 8, and you have a date to move. Do not add a second target "just in case" unless you actually test both. Multi-targeting is a library concern, not an API you deploy once.
net5.0, net6.0, and netcoreapp3.1 should not appear in a new project. If an old solution still has them, the migration is a framework change plus a smoke test, not a rewrite. Most ASP.NET Core code moves. System.Web code does not. That is the real Framework to .NET gap: HttpContext, authentication modules, and config files, not if statements.
How this shows up in the wild
- Docker images should be
mcr.microsoft.com/dotnet/aspnet:10.0, not3.1and not a floatinglatest. Local setup: Docker with Angular. - App Service has to offer the runtime you publish. A
net10.0publish on a stack that only has 8 fails at startup. Azure App Service. - NuGet packages that say they support
.NET Standard 2.0still load. Packages that only supportnet48do not, unless you replace them.
Ecom stack already on this line: Ecom_NET10.