Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Clear out junk files and repair common Windows errors3Fix the driver behind crashes, sound loss and screen glitchesTo use a particular .NET SDK for a project, install that SDK and set its full version in a global.json file at the repository or solution level. The file can require an exact match or allow a defined range of newer SDKs. Run the .NET CLI from the intended directory and check the version it resolves; changing the SDK does not change the project’s target framework or the runtime used to run the application.
Set the SDK version for a project
Microsoft’s global.json documentation describes the file as the way to specify which .NET SDK is used when running .NET CLI commands. Create or edit global.json in the repository or solution directory, then choose a full SDK version and a roll-forward policy.
Require one exact SDK version
Use disable when the requested SDK must be installed exactly, with no fallback:
{
"sdk": {
"version": "9.0.100",
"rollForward": "disable"
}
}The example pins SDK 9.0.100. Replace it with the full version your project requires. Abbreviated values such as 9 or 9.0, and wildcards, are not valid SDK version pins. An exact pin means each developer and CI machine that builds the project needs that SDK installed.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →#1 Best Overall
Allow compatible updates within the same major and minor line
If later feature bands and patches within the same major and minor line are acceptable, specify the minimum version and use latestFeature:
{
"sdk": {
"version": "9.0.100",
"rollForward": "latestFeature"
}
}This lets the resolver choose an installed version at or above the requested version within that major/minor line, including a later feature band. Check that this flexibility matches the team’s build policy. For a starting file, the CLI can generate global.json:
dotnet new globaljson --sdk-version 8.0.302 --roll-forward latestFeatureAdjust the example version and policy to fit the SDK you intend to use.
Use the latest installed SDK
If no applicable global.json specifies a version, the CLI uses the highest installed SDK. That avoids maintaining a version pin, but different developer and CI machines may then use different SDKs.
Choose a roll-forward policy
rollForward controls which installed SDKs are eligible when the requested version is unavailable or the policy permits the resolver to select a newer compatible version. It does not install an SDK. The options documented by Microsoft differ in how far they can move forward:
| Policy | What it permits |
|---|---|
patch |
Prefers the requested version and permits patch-level fallback. This is the default when a version is specified and no policy is set. |
latestPatch |
Selects the highest installed patch in the matching major, minor, and feature band, at or above the requested patch. |
latestFeature |
Selects the highest installed feature band and patch for the requested major/minor, at or above the requested version. |
latestMinor |
Can move to a later minor version, feature band, and patch within the requested major version. |
latestMajor |
Can move to any higher installed SDK version at or above the requested version, including a later major version. |
disable |
Requires an exact version match. |
Choose based on whether the project tolerates SDK changes and how far forward the resolver may move. For projects using lock files, Microsoft recommends an exact SDK selection with roll-forward disabled to avoid SDK updates changing restore behavior; see Upgrade to a new .NET version.
Rank #4
Put global.json where the resolver will find it
Directory location can explain why a command appears to use the wrong SDK. The CLI muxer searches upward from the current working directory for global.json. The MSBuild project SDK resolver instead starts from the solution directory when one is available, otherwise the project directory, and uses the working directory as a final fallback. These different starting points mean that running commands from different directories can produce different results.
Place the file at a deliberate repository or solution boundary, and run commands from the directory expected by your workflow. A global.json in a parent directory can affect a command even when it is not in the project folder.
Verify the selected SDK and fix resolution errors
- Check the working directory. Confirm where the command is being run and whether a
global.jsonin that directory or a parent directory should apply. - Inspect the installed and selected SDKs. Run
dotnet --infoand compare the installed SDK versions with the full version requested inglobal.json. Microsoft’s global.json guidance points to installed-SDK checking information. - Validate the file. Check that the version is complete and spelled correctly, and that the file is in the intended location. A wrong path or unavailable SDK can also prevent selection.
- Install or revise. Install the requested SDK if the pin is intentional, or change the version and roll-forward policy to one the project accepts. For shared work, commit the agreed
global.jsonso team members and CI use the same configuration. - Remove the pin only if you do not want one. Without a version pin, the highest installed SDK is used. Microsoft lists removing
global.jsonas one remedy when pinning is not desired.
The NETSDK1141 troubleshooting page identifies an unavailable SDK, a misspelled version, or an incorrect path as possible causes of an SDK selection failure, and recommends installing the requested SDK, correcting the file, or removing it when a pin is unnecessary.
Use preview SDKs or SDKs in custom locations
The allowPrerelease setting controls whether prerelease SDKs are eligible. If it is omitted, the default depends on the environment: outside Visual Studio, prerelease SDKs are considered by default; inside Visual Studio, preview status and the “Use previews of the .NET SDK” setting affect eligibility. See Microsoft’s global.json reference for the setting and context.
The paths setting is documented for use with the .NET 10 SDK. It searches the listed locations in order, and $host$ represents the location associated with the running dotnet executable. A local SDK location listed before $host$ can take priority when it contains a compatible SDK. Microsoft’s local prerelease SDK guidance explains this feature; it applies to commands that engage the .NET SDK.
Do not confuse the SDK with the target framework or runtime
The SDK supplies the CLI and build tools. The project’s target framework determines which APIs are available at build time, while runtime selection happens when the application runs and follows separate runtime roll-forward rules. A newer SDK can build a project that targets an older framework; setting global.json does not, by itself, change the project target or application runtime. Microsoft explains the distinction in Select which .NET version to use.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
