setup-local-sdk

Installs a project-local .NET SDK and configures global.json paths for isolated SDK resolution.

5.3k|403|Updated Feb 3, 2026
One-click install
npx skills add https://github.com/dotnet/skills --skill setup-local-sdk
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: setup-local-sdk
Source: https://github.com/dotnet/skills/tree/main/plugins/dotnet/skills/setup-local-sdk
Command: npx skills add https://github.com/dotnet/skills --skill setup-local-sdk

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Testing preview .NET SDKs or pinning specific SDK versions normally risks modifying the system-wide installation, breaking other projects. This Skill installs a .NET SDK into a project-local .dotnet/ directory and wires it up via the global.json paths feature (.NET 10+), so the SDK is fully isolated and can be reverted by deleting one folder.

Core Features & Use Cases

  • Isolated SDK Installation: Downloads and installs any .NET SDK channel, quality, or exact version into .dotnet/ using the official dotnet-install scripts on macOS, Linux, or Windows.
  • global.json Configuration: Creates or safely merges the sdk section with paths, rollForward, allowPrerelease, and errorMessage settings while preserving existing properties.
  • Workload and Team Script Support: Installs workloads (e.g., MAUI) using the local dotnet binary and generates reproducible install-dotnet.sh / install-dotnet.ps1 scripts for team and CI setups.
  • Use Case: You want to try the latest .NET 11 preview with the MAUI workload without touching your stable system SDK. The Skill installs it locally, pins it in global.json, gitignores .dotnet/, and commits team install scripts.

Quick Start

Install the latest .NET 11 preview SDK locally for this project and configure global.json so dotnet commands use it automatically.

Frequently Asked Questions about setup-local-sdk

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I install a .NET preview SDK without affecting my system installation?

Install the SDK into a project-local .dotnet directory using the official dotnet-install script, then add a paths entry in global.json pointing to .dotnet. The system-wide SDK stays untouched, and deleting the .dotnet folder fully reverts the setup.

How do I pin a specific .NET SDK version for my project?

Install the exact version with the dotnet-install script's --version flag, then set that version in global.json with rollForward set to disable. This prevents SDK resolution from moving to a different feature band.

Does the global.json paths feature work with older .NET SDKs?

No, the paths feature requires a .NET 10 or later host SDK installed system-wide. If dotnet --version reports a major version below 10, you must install .NET 10 or later globally before using local SDK resolution.

Why are my installed workloads missing after a local SDK setup?

Workloads were likely installed with the system dotnet instead of the local binary, so metadata went to the wrong location. Always run workload commands with the local binary, such as ./.dotnet/dotnet workload install.

Can I install the MAUI workload on a local SDK on Linux?

The full maui meta-workload is not available on Linux. Use a supported workload such as maui-android when Android is the target, installed via the local dotnet binary after global.json is configured.

When should I not use a project-local .NET SDK install?

Avoid it for system-wide installs, runtime-only installs, or hosts older than .NET 10 since paths only applies to SDK resolution. Use the official system installer or set DOTNET_ROOT for runtime scenarios instead.