setup-local-sdk

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

Updated Jul 20, 2026
One-click install
npx skills add https://github.com/Netcodr81/kinetic-reports --skill setup-local-sdk-netcodr81
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: setup-local-sdk
Source: https://github.com/Netcodr81/kinetic-reports/tree/main/.github/skills/setup-local-sdk
Command: npx skills add https://github.com/Netcodr81/kinetic-reports --skill setup-local-sdk-netcodr81

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Installing preview or specific .NET SDK versions system-wide risks breaking existing projects and is hard to revert. This Skill installs a .NET SDK into a project-local .dotnet/ directory and wires it up via the global.json paths feature, leaving the system-wide installation untouched. ## 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 merges the sdk section with version, rollForward, allowPrerelease, and paths settings while preserving existing properties. - Team & CI Scripts: Generates install-dotnet.sh and install-dotnet.ps1 so teammates and CI pipelines can reproduce the exact SDK setup. - Use Case: You want to test a .NET 11 preview with the MAUI workload without touching your stable system SDK. The Skill installs the preview locally, pins it in global.json, gitignores .dotnet/, and installs the workload using the local dotnet binary. ## Quick Start Ask the assistant to install the latest .NET 11 preview SDK locally for this project and configure global.json to use it.

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 SDK locally without affecting the system installation?▼

Run the official dotnet-install script with --install-dir .dotnet to place the SDK in a project-local folder, then add "paths": [".dotnet", "$host$"] to global.json. The dotnet host resolves the local SDK first, and deleting .dotnet reverts everything.

How do I test a .NET preview SDK safely alongside my stable version?▼

Install the preview into .dotnet using --channel and --quality preview flags, then pin the exact version in global.json with allowPrerelease set to true. The system-wide stable SDK remains untouched and serves as fallback via $host$.

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

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

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

Workloads were likely installed with the system dotnet instead of the local binary. Workload metadata is stored relative to the host process's dotnet root, so always run ./.dotnet/dotnet workload install to keep workloads with the local SDK.

Can I create reproducible SDK install scripts for my team or CI?▼

Yes, generate install-dotnet.sh and install-dotnet.ps1 scripts that download the SDK, write global.json with an errorMessage, and update .gitignore. Committing these scripts lets teammates reproduce the exact SDK setup with one command.