The problem
Different projects can need exact .NET SDK versions without changing the SDK configuration of an entire machine.
The repository documents this need in the context of evaluating newer .NET versions while retaining a predictable everyday development environment.
The underlying question is not simply whether the project can perform a task, but how that task can remain understandable, repeatable, and safe as conditions change.
The solution
Manage selected SDK versions within a user-owned directory, leaving system-wide SDKs and PATH untouched.
An installation is staged under ~/dotnet-sdks, verified against Microsoft's checksums and the requested exact SDK version, then promoted into the isolated inventory. List, audit, verify, and remove have distinct responsibilities.
Choose it when testing a prerelease SDK, reproducing a version-specific issue, or using an SDK outside a team's regular machine setup.
Who it's for
Developers and CI maintainers who need predictable SDK versions without system-wide changes.
A practical fit is a reader or maintainer who wants a defined workflow and documented boundaries rather than an unexplained one-off operation.
Choose it when testing a prerelease SDK, reproducing a version-specific issue, or using an SDK outside a team's regular machine setup.
How it works
Key capabilities and concepts. See the project documentation or source code for implementation details.
Install and remove specific SDK versions in a user-owned directory
Install and remove specific SDK versions in a user-owned directory.
An installation is staged under ~/dotnet-sdks, verified against Microsoft's checksums and the requested exact SDK version, then promoted into the isolated inventory. List, audit, verify, and remove have distinct responsibilities.
Audit and verify the installed SDK inventory
Audit and verify the installed SDK inventory.
This is filesystem isolation, not a security sandbox. The SDK still runs with the current user's permissions; explicit invocation replaces transparent PATH switching.
PowerShell support on Windows and Bash support on Linux and macOS
PowerShell support on Windows and Bash support on Linux and macOS.
Choose it when testing a prerelease SDK, reproducing a version-specific issue, or using an SDK outside a team's regular machine setup.
Design decisions that matter
- Isolation over global machine changes.
Isolation over global machine changes.
This is filesystem isolation, not a security sandbox. The SDK still runs with the current user's permissions; explicit invocation replaces transparent PATH switching.
- Explicit, verifiable SDK versions.
Explicit, verifiable SDK versions.
The repository documents this need in the context of evaluating newer .NET versions while retaining a predictable everyday development environment.
- PowerShell on Windows and Bash on Linux/macOS.
PowerShell on Windows and Bash on Linux/macOS.
An installation is staged under ~/dotnet-sdks, verified against Microsoft's checksums and the requested exact SDK version, then promoted into the isolated inventory. List, audit, verify, and remove have distinct responsibilities.
Explore the implementation
Installation, audit, verification, and removal are documented; consult the repository and published docs for current examples and limitations.
This is filesystem isolation, not a security sandbox. The SDK still runs with the current user's permissions; explicit invocation replaces transparent PATH switching.
For exact current usage, prerequisites, and release status, consult the source repository and published documentation.
Related articles
Engineering context and lessons behind this project.
Managing .NET SDKs: Installation Was Just the Beginning ↗
How the isolated SDK utility evolved to support version inventory, verification, and auditing.
How to Test a New .NET SDK Without Installing It System-Wide ↗
Why isolated SDK installations help with prerelease evaluation and reproducible .NET workflows.