What .NET is: runtime, libraries and support policy
The CLR, the base class library and the release cadence, plus how to choose between .NET and .NET Framework for a service that has to live for years.
The parts of the platform
| Part | What it is | You interact with it by |
|---|---|---|
| CLR / CoreCLR | The runtime: JIT, GC, type system, threading | dotnet run, hosting APIs, runtime configuration |
| BCL | The base class library: collections, IO, networking, JSON | System.* namespaces |
| SDK | Compiler, CLI, templates, MSBuild targets | The dotnet command |
| ASP.NET Core | Web framework shipped in the shared framework | The Microsoft.AspNetCore.App framework reference |
| Runtimes | Microsoft.NETCore.App, AspNetCore.App, WindowsDesktop.App | The TargetFramework and runtime identifier you publish for |
# What is installed, and which runtimes a machine actually has
dotnet --version
dotnet --list-sdks
dotnet --list-runtimes
# The same information, machine readable, for a build script
dotnet --info --json | head -40
# What a published application was actually built against
dotnet myapp.dll --info 2>/dev/null || truePublishing a framework-dependent app produces a small DLL that needs a matching runtime installed. Publishing self-contained produces everything, including the runtime, in a much larger directory. Both are legitimate; the choice is about who patches the runtime.
LTS, STS and picking a target
| Release type | Support | Choose it when |
|---|---|---|
| LTS | Three years from release | Anything in production, default choice |
| STS | Eighteen months | You need a specific new feature and can upgrade on schedule |
| Out of support | Security fixes only, then nothing | Never, for anything reachable |
- A framework-dependent app refuses to start if the exact major version it targets is missing, unless roll-forward is configured.
RollForward=LatestMajorlets an app start on a newer runtime, which is useful in containers and risky on shared servers where the runtime changes without you.- Framework-dependent deployments mean the runtime receives security patches from the platform's package manager, which is usually what an operations team wants.
- Self-contained deployments give you reproducibility at the cost of a bigger image and a rebuild for every runtime patch.
- Native AOT produces a machine-code binary with no runtime to install, but reflection-heavy code, dynamic serialisation and much of the ecosystem will not work with it.
- .NET Framework to .NET migration is a port, not a rebuild: APIs differ, and Windows-only dependencies such as WebForms do not exist on modern .NET.
<!-- Pin the runtime band a machine may use -->
<PropertyGroup>
<TargetFramework>net8.0</TargetFramework>
<RollForward>LatestMinor</RollForward>
</PropertyGroup>{
"sdk": { "version": "8.0.400", "rollForward": "latestFeature" }
}💡
Treat the runtime upgrade as a scheduled piece of work, not an incident. An LTS release gives you three years, but only if you actually move inside that window — teams that ignore it end up doing an emergency upgrade while a security advisory is open.
FAQ
Is .NET Core the same thing as .NET 8?
Yes. The name was simplified at version 5, so ".NET Core 3.1" was the last release under the old name and everything from .NET 5 onward is just called .NET. The runtime is still cross-platform.
Should I use LTS or the newest release?
LTS for anything that must run unattended. Take an STS release when a specific feature removes real work, and plan the upgrade before you adopt it.
Related
Project types, target frameworks and multi-targeting The dotnet CLI workflow
Last refreshed 2026-09-18.