NETSDK1045: 'The current .NET SDK does not support targeting .NET 10.0' with a global.json pin

error NETSDK1045: The current .NET SDK does not support targeting .NET 10.0. on a machine that has the .NET 10 SDK installed means a global.json pins an older SDK, so the build runs on that one. Change the pinned version to an installed .NET 10 SDK and the project builds.

The path in the error gives it away: sdk\8.0.425\Sdks\.... Run dotnet --version in the project folder; if it prints an 8.0 or 9.0 version while you have 10.0 installed, a global.json chose it.

The error

  Determining projects to restore...
C:\Program Files\dotnet\sdk\8.0.425\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.TargetFrameworkInference.targets(166,5): error NETSDK1045: The current .NET SDK does not support targeting .NET 10.0.  Either target .NET 8.0 or lower, or use a version of the .NET SDK that supports .NET 10.0. Download the .NET SDK from https://aka.ms/dotnet/download [C:\...\n45b\n45b.csproj]

Build FAILED.

Only the project path was shortened; the double space after the first sentence is in the original.

Why it happens

An SDK can only build for the .NET versions it knows, and the 8.0 SDK says so itself: target .NET 8.0 or lower. On this machine SDK 10.0.401 is installed and is the default everywhere else, but the project folder holds a global.json containing { "sdk": { "version": "8.0.425" } }. The dotnet host obeys that file for every command in the folder and its subfolders, so dotnet --version printed 8.0.425, and both dotnet build and dotnet restore stopped with NETSDK1045.

This is what you get when a project is moved to net10.0 and the repository's global.json still names the old SDK, or when you clone a repository in that state. Installing another SDK, as the message suggests, would not help here: 10.0.401 is already installed, and the pin keeps it out.

The fix

{ "sdk": { "version": "10.0.401" } }

> dotnet --version
10.0.401
> dotnet build
  Determining projects to restore...
  Restored C:\...\n45b\n45b.csproj (in 82 ms).
  n45b -> C:\...\n45b\bin\Debug\net10.0\n45b.dll

Build succeeded.

Name an SDK that every machine building the repository has, CI agents included. Two other edits also built. { "sdk": { "version": "10.0.100", "rollForward": "latestFeature" } } accepts any 10.0 SDK from 10.0.100 up, which is kinder to teammates on a different patch. Keeping 8.0.425 with "rollForward": "latestMajor" picked 10.0.401 too, but then the file no longer pins anything. One edit that looks right did not work: 10.0.100 with no rollForward failed with a different error, because no 10.0.1xx release SDK is installed.

The other way out, the one the message offers first, is to change <TargetFramework> to net8.0 and leave the pin alone. That also built, but it only makes sense if the project is meant to stay on .NET 8.

How it was reproduced

A console app from dotnet new console created with SDK 10.0.401, so it targets net10.0, then a global.json pinning 8.0.425 written next to the .csproj, then dotnet build. Windows 11 with SDKs 8.0.425, 9.0.317, 10.0.100-rc.1.25451.107 and 10.0.401 installed. After the fix, a subfolder without its own global.json resolved the same SDK as the project folder.

Frequently asked

How do I fix NETSDK1045 when .NET 10 is installed?

Run dotnet --version in the project folder. If it prints an older SDK, find the global.json in that folder or a parent and set its sdk version to an installed .NET 10 SDK, or use version 10.0.100 with rollForward latestFeature.

Why does dotnet build use the .NET 8 SDK when .NET 10 is installed?

A global.json in the project folder or one of its parents pins an 8.0 SDK. The dotnet host follows that file for every command in the folder tree, whatever newer SDKs are installed.

Should I change TargetFramework to net8.0 to fix NETSDK1045?

Only if the project is meant to run on .NET 8. Retargeting to net8.0 with the 8.0 SDK pinned builds, but it gives up .NET 10. If the project was upgraded on purpose, update global.json instead.

More decoded errors in the Fixes category. If editing global.json leaves you with A compatible .NET SDK was not found, the rollForward values are tested one by one in this post.