Image retained from the original article.
Originally published 21 June 2023; rewritten and reviewed on 15 October 2026.
A machine can report that dotnet exists while still running the wrong SDK for a project. Several installations, shell paths and package sources make that possible. I would start by identifying the distribution and the project requirements before installing another copy.
Choose the component and installation route
A build machine needs an SDK. A framework-dependent production application may need only the compatible runtime or ASP.NET Core runtime. A self-contained application changes that requirement but can still depend on native operating-system components.
Use Microsoft’s Linux installation documentation for the distribution, architecture and supported release you actually intend to use. Package-manager, scripted and manual installations have different update and ownership behaviour.
Do not execute an archive as a program
The original article included a command that attempted to run a .tar.gz SDK archive. A compressed archive must instead be extracted into the chosen location, following the manual-installation instructions. Select an official download and verify its integrity through the published method before using it.
Avoid mixing distribution packages and manual installations without understanding their paths. Record the chosen source so security updates do not depend on somebody remembering how the machine was configured.
Verify the resolved installation
command -v dotnet
dotnet --info
dotnet --list-sdks
dotnet --list-runtimes
Compare the output with the project’s target and any global.json SDK selection. Build a small known project and run it under the identity that will perform the real work.
The installation is ready when the team can explain which SDK or runtime is used, where it came from and how it will be maintained. A successful download alone cannot answer those questions.