Editorial illustration.
Originally published 21 June 2023; rewritten and reviewed on 15 October 2026.
A copied download command can outlive the release it was written for. The original article named a .NET Core 3.1 SDK archive; that historical URL should not decide the version installed on a machine today.
Select the release before writing the command
Check the application’s supported target, the machine architecture and the distribution requirements. Obtain the artefact URL and verification information from Microsoft’s official download or installation documentation. Decide whether you need an SDK, a runtime or an ASP.NET Core runtime.
The transport itself can remain simple:
# Substitute an official HTTPS artefact URL selected for your platform.
curl --fail --location --output dotnet-package.tar.gz "$DOTNET_DOWNLOAD_URL"
# Compare the checksum with the independently published official value.
sha512sum dotnet-package.tar.gz
This is a command pattern with an intentionally supplied URL, not a complete unattended installer. Quoting the variable prevents the shell from splitting it unexpectedly. --fail helps avoid saving an HTTP error page as though it were a package.
Keep verification and installation separate
A checksum is useful only when the expected value comes from a trusted source. Inspect the selected version and archive type, then follow the documented extraction or package-install procedure. Do not run a compressed archive as a shell script.
For automated provisioning, pin the intended artefact and update that choice through a maintained process. Avoid a command whose meaning silently changes each time the build runs.
Verify the result at the next stage
After installation, use dotnet --info and the SDK/runtime lists to confirm what the host resolves. Keep a record of the version and source. The reliable workflow is selection, download, verification and installation—not an old URL copied into a terminal and forgotten.