SECURITY WARNING: Never run commands you don't understand. Always review code before execution. Use at your own risk.
C# New Added 15 October 2026

.NET: NETSDK1045: The current .NET SDK does not support targeting .NET 10.0

The project's TargetFramework is newer than the SDK doing the build. Installing the new runtime is not enough, you need the matching SDK. The usual surprise is a global.json pinning an older SDK, or a CI image or Visual Studio install that lags behind, so the project builds on one machine and not another while dotnet --list-sdks shows the right version somewhere.

Quick fix

Read the commands before running them. Anything that restarts a service, deletes data or changes permissions should be tried on a non-production system first.

Quick fix
# Which SDK is picked for this folder, and which are installed?
dotnet --version
dotnet --list-sdks

# A global.json in this or a parent folder can pin an older SDK
find . .. -maxdepth 2 -name global.json -exec cat {} \;

# Install the SDK that matches the TargetFramework
# winget install Microsoft.DotNet.SDK.10
# Linux: https://dot.net/v1/dotnet-install.sh -c 10.0

# Or allow roll-forward to a newer installed SDK in global.json
# { "sdk": { "version": "10.0.100", "rollForward": "latestFeature" } }

# GitHub Actions: install it explicitly
# - uses: actions/setup-dotnet@v4
#   with: { dotnet-version: '10.0.x' }

How to diagnose C# errors

C# errors divide into compile-time and restore-time problems (NuGet resolution, target framework mismatches) and runtime problems dominated by null references and async misuse. The classic .NET production hazard is the sync-over-async deadlock, calling .Result or .Wait() on a task in a context with a synchronisation context, which manifests as a hang rather than an exception and is therefore much harder to spot.

If the quick fix above does not resolve it, work through these steps. They apply to this whole class of error, not just to this one message, which is usually what saves the time.

  1. Run dotnet restore --verbosity detailed to see which feed each package resolved from. Most restore failures are a private feed with expired credentials, not a missing package.
  2. Enable nullable reference types (<Nullable>enable</Nullable>) and treat the warnings as errors. This converts a whole class of production NullReferenceExceptions into compile failures.
  3. For async hangs, search the codebase for .Result, .Wait() and .GetAwaiter().GetResult(). Replace with await all the way up, or use ConfigureAwait(false) in library code.
  4. For EF Core, run dotnet ef migrations list to see which migrations the database believes are applied before generating a new one.
  5. Capture a dump with dotnet-dump and inspect it with dotnet-gcdump / dotnet-counters when the process misbehaves without throwing.

Tools worth reaching for

  • dotnet restore -v detailed
  • dotnet ef migrations list
  • dotnet-counters
  • dotnet-dump

Authoritative references

Primary documentation for this error, worth reading before applying any fix in production.

learn.microsoft.com learn.microsoft.com

Related C# errors

See all 18 C# errors →

Browse other categories

Something missing or wrong?

This entry is maintained by hand. If the fix is out of date, incomplete, or you have a better one, email a correction and it will be reviewed.