What are target framework monikers like net8.0, net9.0 and net10.0, how do you choose one, and when should you multi-target?

1. What a TFM controls

<TargetFramework>net10.0</TargetFramework>
        |
        +--> reference assemblies   Microsoft.NETCore.App.Ref 10.0 (the API surface you compile against)
        +--> preprocessor symbols   NET, NET10_0, NET10_0_OR_GREATER, NET9_0_OR_GREATER, NET8_0_OR_GREATER ...
        +--> NuGet asset selection  lib/net10.0, else the nearest compatible folder
        +--> runtimeconfig.json     "framework": { "name": "Microsoft.NETCore.App", "version": "10.0.0" }
        +--> default C# version     C# 14 for net10.0, C# 13 for net9.0, C# 12 for net8.0
        +--> analyser defaults      AnalysisLevel follows the TFM, so newer targets get newer rules

The TFM is about the API surface and runtime, not the SDK. The .NET 10 SDK builds net8.0, net9.0 and net10.0 projects; global.json chooses the SDK, the TFM chooses what the output runs on.

2. Anatomy of a TFM

For OS TFMs, SupportedOSPlatformVersion sets the minimum OS version you support (it can be lower than the version in the TFM, which only sets which APIs you compile against).

3. The support lifecycle (as at October 2026)

Rules of thumb:

• A new major version ships every November. Even numbers are LTS (three years), odd numbers are STS (24 months since .NET 9).
• Patches arrive on "Patch Tuesday" each month. Only the latest patch of a supported version is supported.
• After end of support there are no security fixes. For systems that handle personal information, or that follow the Essential Eight's patching controls, running an unsupported runtime is a finding in any audit.

4. Choosing a target

 Is it an application or service you deploy?
    yes --> one TFM: the newest LTS (net10.0). Plan the next LTS upgrade early.
    no  --> it's a library. Who consumes it?
              only your own apps on .NET 10      --> net10.0
              apps still moving from .NET 8      --> net8.0;net10.0 (drop net8.0 soon)
              .NET Framework consumers too       --> netstandard2.0 (+ net10.0 for newer APIs)
              Roslyn analyser / source generator --> netstandard2.0 (required)
              Unity or other Mono runtimes       --> netstandard2.0 or netstandard2.1

5. How NuGet picks the right folder

A package can contain several lib/<tfm>/ folders. NuGet picks the nearest compatible one for the consuming project:

This is why a library that multi-targets net8.0;net10.0 still serves a net9.0 consumer: it gets the net8.0 build.

6. Multi-targeting: what actually happens

<TargetFrameworks>net8.0;net10.0</TargetFrameworks>
        |
   outer build ---+--> inner build (TargetFramework=net8.0)  --> bin/Release/net8.0/
   (dispatches)   +--> inner build (TargetFramework=net10.0) --> bin/Release/net10.0/
        |
   dotnet pack  --> one .nupkg with lib/net8.0/ and lib/net10.0/
   dotnet test  --> runs the tests once per target framework

• Every inner build restores, compiles and runs analysers separately, so build time grows with each target.
• dotnet build -f net10.0 builds one target only, which is handy locally.
• Properties and items can differ per target with conditions on $(TargetFramework).
• To compare TFMs in conditions, prefer $([MSBuild]::IsTargetFrameworkCompatible('$(TargetFramework)', 'net10.0')) over string comparison when you mean "this target or newer".

Handling API differences

The common symbols: NET, NETCOREAPP, NETFRAMEWORK, NETSTANDARD, versioned forms such as NET10_0 and NET8_0_OR_GREATER, and OS symbols such as WINDOWS, ANDROID and IOS for OS-specific TFMs.

7. Runtime roll forward

A framework-dependent net8.0 app asks for the .NET 8 runtime. By default it runs on the newest installed 8.0.x patch; it does not move to .NET 10 on its own.

Major lets an old app start on a newer runtime, but it hasn't been tested there. When a version reaches end of support, the fix is to retarget and test, not to rely on roll forward.

8. Upgrading a target framework

1. Put the TFM in Directory.Build.props (for example <TargetFramework>net10.0</TargetFramework>) so the change is one line for the whole repo.
2. Pin the new SDK in global.json.
3. Read the breaking-changes page for every version you skip (going from .NET 8 to .NET 10 means reading the .NET 9 and .NET 10 lists).
4. Update Microsoft packages (Microsoft.Extensions.*, Microsoft.AspNetCore.*, EF Core) to the matching major version.
5. Build, fix new warnings (newer analysers come with the newer TFM), and run all tests.
6. Update Docker base images, CI agent images and hosting (App Service stack, Functions runtime) to the new runtime.
7. Deploy to a non-production environment and watch performance and error rates before production.

9. Library-specific checks

• Turn on <EnablePackageValidation>true</EnablePackageValidation> so dotnet pack checks that every target exposes a compatible API, and set PackageValidationBaselineVersion to catch breaking changes against the last release.
• Run tests for every target framework in CI, not just the newest.
• Removing a target framework is a breaking change for consumers on it. Announce it and bump the major version.

10. .NET 11 awareness

.NET 11 (net11.0) is due in November 2026 as an STS release with 24 months of support. Try it in a branch with its own global.json, or add net11.0 to a library's TargetFrameworks in a preview build only. Keep production applications on net10.0 (LTS) until .NET 11 has shipped and you have tested it, and remember that many organisations prefer to move from LTS to LTS (.NET 10 to .NET 12).

11. Try it yourself

1. Create a class library and set <TargetFrameworks>net8.0;net10.0</TargetFrameworks> (plural).
2. Add a method that uses #if NET10_0_OR_GREATER, build, and look in bin/Debug/ for two folders.
3. Run dotnet pack and open the .nupkg (it's a zip) to see lib/net8.0 and lib/net10.0.
4. Run dotnet build -f net8.0 to build only one target.
5. Create a net9.0 console app that references the library and check which folder it uses in obj/project.assets.json.
6. Change the singular <TargetFramework> to net8.0;net10.0 and read the error.
7. In a console app, open bin/Debug/net10.0/*.runtimeconfig.json and read the framework version and roll-forward setting.

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFrameworks>net8.0;net10.0</TargetFrameworks>
    <Nullable>enable</Nullable>
    <ImplicitUsings>enable</ImplicitUsings>
  </PropertyGroup>

  <!-- Only the net8.0 build needs this polyfill package -->
  <ItemGroup Condition="'$(TargetFramework)' == 'net8.0'">
    <PackageReference Include="Contoso.Polyfills" Version="1.2.0" />
  </ItemGroup>
</Project>

namespace Contoso.Telemetry;

public sealed class Counter
{
#if NET10_0_OR_GREATER
    private readonly Lock _gate = new();
#else
    private readonly object _gate = new();
#endif
    private long _value;

    public long Increment()
    {
        lock (_gate)
        {
            return ++_value;
        }
    }
}

System.Threading.Lock arrived in .NET 9, so NET9_0_OR_GREATER would also work; the example uses the .NET 10 symbol because those are the two targets.