Your .NET 10 Project Is Using the .NET 11 SDK—Here’s the Fix
Published 27/10/2026
Description
Your project targets .NET 10—but is it still building with the .NET 10 SDK? In this hands-on walkthrough, I show how a Visual Studio Insiders update introduced a .NET 11 release candidate SDK into my development environment, and how I use global.json to keep my production builds on .NET 10. 0:00 - Introduction 0:14 - Description 1:19 - Release Pipeline 2:22 - Nuget API Key 3:29 - Nuget Trusted Publisher 4:50 - Conclusion The distinction matters: your project’s target framework and the SDK selected to build it are separate settings. Seeing net10.0 in your build output does not tell you which SDK performed the build. Using a simple .NET 10 library and test project, I investigate SDK selection in the command line and Visual Studio, inspect diagnostic output, and configure an explicit SDK selection policy. In this video, you’ll learn: How a Visual Studio update can introduce a newer .NET SDK. Why a .NET 10 project can build using a .NET 11 SDK. How to inspect installed SDKs and check the selected version. How diagnostic build and test output reveals the SDK being used. How to configure the sdk section in global.json. The differences between disable, latestPatch, and latestFeature roll-forward policies. How allowPrerelease: false excludes preview and release candidate SDKs from selection. Why parent and repository-level global.json files do not merge. Why committing global.json to each repository helps share SDK selection settings. How to preserve an existing Microsoft.Testing.Platform configuration while adding SDK settings. In my example, I select SDK 10.0.402 with latestFeature and allowPrerelease set to false. This allows eligible installed SDK updates within .NET 10.0 without selecting .NET 11 or a prerelease SDK. I also demonstrate a configuration trap: placing an SDK policy in a parent directory does not help when a closer global.json is selected instead—even if that closer file only configures the test runner. The go