Installing net on linux

Install .NET on Linux

.NET is available on different Linux distributions. Most Linux platforms and distributions have a major release each year, and most provide a package manager that is used to install .NET. This article describes what is currently supported and which package manager is used.

The rest of this article is a breakdown of each major Linux distribution that .NET supports. All .NET releases remain supported until either the version of .NET reaches end-of-support or the Linux distribution reaches end-of-life.

For the best compatibility, choose a long-term release (LTS) version.

Unsupported releases

The following versions of .NET are вќЊ no longer supported. The downloads for these still remain published:

These unsupported versions aren’t detailed in the sections below and your mileage may vary if you try to install them.

Manual installation

If you don’t want to use a package manager to install .NET on Linux, you can install .NET in one of the following ways:

Be sure to check the appropriate distribution page for more information about any required dependencies that may be missing when you do a manual installation.

Install preview versions

Preview and Release Candidate versions of .NET aren’t available in package managers. You can install previews and release candidates of .NET manually.

Alpine

The following table is a list of currently supported .NET releases and the versions of Alpine they’re supported on. These versions remain supported until either the version of .NET reaches end-of-support or the version of Alpine reaches end-of-life.

• A вњ”пёЏ indicates that the version of Alpine or .NET is still supported.
• A вќЊ indicates that the version of Alpine or .NET isn’t supported on that Alpine release.
• When both a version of Alpine and a version of .NET have вњ”пёЏ, that OS and .NET combination is supported.

Alpine	.NET Core 2.1	.NET Core 3.1	.NET 5.0
вњ”пёЏ 3.13	вњ”пёЏ 2.1	вњ”пёЏ 3.1	вњ”пёЏ 5.0
вњ”пёЏ 3.12	вњ”пёЏ 2.1	вњ”пёЏ 3.1	вњ”пёЏ 5.0
вњ”пёЏ 3.11	вњ”пёЏ 2.1	вњ”пёЏ 3.1	вњ”пёЏ 5.0
вњ”пёЏ 3.10	вњ”пёЏ 2.1	вњ”пёЏ 3.1	вќЊ 5.0
вќЊ 3.9	вњ”пёЏ 2.1	вњ”пёЏ 3.1	вќЊ 5.0
вќЊ 3.8	вњ”пёЏ 2.1	вњ”пёЏ 3.1	вќЊ 5.0

CentOS

CentOS 7 uses Yum as a package manager and CentOS 8 uses DNF.

The following table is a list of currently supported .NET releases on both CentOS 7 and CentOS 8. These versions remain supported until either the version of .NET reaches end-of-support or the version of CentOS is no longer supported.

CentOS	.NET Core 2.1	.NET Core 3.1	.NET 5.0
вњ”пёЏ 8	вњ”пёЏ 2.1	вњ”пёЏ 3.1	вњ”пёЏ 5.0
вњ”пёЏ 7	вњ”пёЏ 2.1	вњ”пёЏ 3.1	вњ”пёЏ 5.0

Debian

Debian uses APT (Advanced Package Tool) as a package manager.

The following table is a list of currently supported .NET releases and the versions of Debian they’re supported on. These versions remain supported until either the version of .NET reaches end-of-support or the version of Debian reaches end-of-life.

• A вњ”пёЏ indicates that the version of Debian or .NET is still supported.
• A вќЊ indicates that the version of Debian or .NET isn’t supported on that Debian release.
• When both a version of Debian and a version of .NET have вњ”пёЏ, that OS and .NET combination is supported.

Debian	.NET Core 2.1	.NET Core 3.1	.NET 5.0
вњ”пёЏ 11	вњ”пёЏ 2.1	вњ”пёЏ 3.1	вњ”пёЏ 5.0
вњ”пёЏ 10	вњ”пёЏ 2.1	вњ”пёЏ 3.1	вњ”пёЏ 5.0
вњ”пёЏ 9	вњ”пёЏ 2.1	вњ”пёЏ 3.1	вњ”пёЏ 5.0
вќЊ 8	вњ”пёЏ 2.1	вќЊ 3.1	вќЊ 5.0

Fedora

Fedora uses DNF as its package manager.

The following table is a list of currently supported .NET releases and the versions of Fedora they’re supported on. These versions remain supported until either the version of .NET reaches end-of-support or the version of Fedora reaches end-of-life.

• A вњ”пёЏ indicates that the version of Fedora or .NET is still supported.
• A вќЊ indicates that the version of Fedora or .NET isn’t supported on that Fedora release.
• When both a version of Fedora and a version of .NET have вњ”пёЏ, that OS and .NET combination is supported.

Fedora	.NET Core 2.1	.NET Core 3.1	.NET 5.0
вњ”пёЏ 34	вњ”пёЏ 2.1	вњ”пёЏ 3.1	вњ”пёЏ 5.0
вњ”пёЏ 33	вњ”пёЏ 2.1	вњ”пёЏ 3.1	вњ”пёЏ 5.0
вњ”пёЏ 32	вњ”пёЏ 2.1	вњ”пёЏ 3.1	вњ”пёЏ 5.0
вќЊ 31	вњ”пёЏ 2.1	вњ”пёЏ 3.1	вќЊ 5.0
вќЊ 30	вњ”пёЏ 2.1	вњ”пёЏ 3.1	вќЊ 5.0
вќЊ 29	вњ”пёЏ 2.1	вњ”пёЏ 3.1	вќЊ 5.0
вќЊ 28	вњ”пёЏ 2.1	вќЊ 3.1	вќЊ 5.0
вќЊ 27	вњ”пёЏ 2.1	вќЊ 3.1	вќЊ 5.0

openSUSE

openSUSE uses zypper as the package manager.

The following table is a list of currently supported .NET releases on openSUSE 15. These versions remain supported until either the version of .NET reaches end-of-support or the version of openSUSE is no longer supported.

openSUSE	.NET Core 2.1	.NET Core 3.1	.NET 5.0
вњ”пёЏ 15	вњ”пёЏ 2.1	вњ”пёЏ 3.1	вњ”пёЏ 5.0

Red Hat

Red Hat Enterprise Linux (RHEL) uses yum (RHEL 7) and DNF (RHEL 8) as the package manager.

The following table is a list of currently supported .NET releases on both RHEL 7 and RHEL 8. These versions remain supported until either the version of .NET reaches end-of-support or the version of RHEL is no longer supported.

• A вњ”пёЏ indicates that the version of RHEL or .NET is still supported.
• A вќЊ indicates that the version of RHEL or .NET isn’t supported on that RHEL release.
• When both a version of RHEL and a version of .NET have вњ”пёЏ, that OS and .NET combination is supported.

RHEL	.NET Core 2.1	.NET Core 3.1	.NET 5.0
вњ”пёЏ 8	вњ”пёЏ 2.1	вњ”пёЏ 3.1	вњ”пёЏ 5.0
вњ”пёЏ 7	вњ”пёЏ 2.1	вњ”пёЏ 3.1	вњ”пёЏ 5.0

For more information, see Install .NET on RHEL.

SLES uses zypper as the package manager.

The following table is a list of currently supported .NET releases on both SLES 12 SP2 and SLES 15. These versions remain supported until either the version of .NET reaches end-of-support or the version of SLES is no longer supported.

• A вњ”пёЏ indicates that the version of SLES or .NET is still supported.
• A вќЊ indicates that the version of SLES or .NET isn’t supported on that SLES release.
• When both a version of SLES and a version of .NET have вњ”пёЏ, that OS and .NET combination is supported.

SLES	.NET Core 2.1	.NET Core 3.1	.NET 5.0
вњ”пёЏ 15	вњ”пёЏ 2.1	вњ”пёЏ 3.1	вњ”пёЏ 5.0
вњ”пёЏ 12 SP2	вњ”пёЏ 2.1	вњ”пёЏ 3.1	вњ”пёЏ 5.0

For more information, see Install .NET on SLES.

Ubuntu

Ubuntu uses APT (Advanced Package Tool) as a package manager.

The following table represents the support status of Ubuntu and .NET.

Источник

Install the .NET SDK or the .NET Runtime with Snap

Use a Snap package to install the .NET SDK or .NET Runtime. Snaps are a great alternative to the package manager built into your Linux distribution. This article describes how to install .NET through Snap.

A snap is a bundle of an app and its dependencies that works without modification across many different Linux distributions. Snaps are discoverable and installable from the Snap Store. For more information about Snap, see Getting started with Snap.

Snap packages aren’t supported in WSL2 on Windows 10. As an alternative, use the dotnet-install script or the package manager for the particular WSL2 distribution. It’s not recommended but you can try to enable snap with an unsupported workaround from the snapcraft forums.

.NET releases

Only вњ”пёЏ supported versions of .NET SDK are available through Snap. All versions of the .NET Runtime are available through snap starting with version 2.1. The following table lists the .NET (and .NET Core) releases:

вњ”пёЏ Supported	вќЊ Unsupported
5.0	3.0
3.1 (LTS)	2.2
2.1 (LTS)	2.0
1.1
1.0

For more information about the life cycle of .NET releases, see .NET Core and .NET 5 Support Policy.

SDK or Runtime

Install the SDK (which includes the runtime) if you want to develop .NET apps. Or, if you only need to run apps, install the Runtime. If you’re installing the Runtime, we suggest you install the ASP.NET Core Runtime as it includes both .NET and ASP.NET Core runtimes.

If you’ve already installed the SDK or Runtime, use the dotnet —list-sdks and dotnet —list-runtimes commands to see which versions are installed. For more information, see How to check that .NET is already installed.

Install the SDK

Snap packages for the .NET SDK are all published under the same identifier: dotnet-sdk . A specific version of the SDK can be installed by specifying the channel. The SDK includes the corresponding runtime. The following table lists the channels:

.NET version	Snap package or channel
5.0	5.0 or latest/stable
3.1 (LTS)	3.1 or lts/stable
2.1 (LTS)	2.1

Use the snap install command to install a .NET SDK snap package. Use the —channel parameter to indicate which version to install. If this parameter is omitted, latest/stable is used. In this example, 5.0 is specified:

Next, register the dotnet command for the system with the snap alias command:

This command is formatted as: sudo snap alias . . You can choose any name you would like. For example, you could name the command after the specific version installed by snap: sudo snap alias dotnet-sdk.dotnet dotnet50 . When you use the command dotnet50 , you’ll invoke this specific version of .NET. But choosing a different alias is incompatible with most tutorials and examples as they expect a dotnet command to be used.

Install the runtime

Snap packages for the .NET Runtime are each published under their own package identifier. The following table lists the package identifiers:

.NET version	Snap package
5.0	dotnet-runtime-50
3.1 (LTS)	dotnet-runtime-31
3.0	dotnet-runtime-30
2.2	dotnet-runtime-22
2.1 (LTS)	dotnet-runtime-21

Use the snap install command to install a .NET Runtime snap package. In this example, .NET 5.0 is installed:

Next, register the dotnet command for the system with the snap alias command:

The command is formatted as: sudo snap alias . . You can choose any name you would like. For example, you could name the command after the specific version installed by snap: sudo snap alias dotnet-runtime-50.dotnet dotnet50 . When you use the command dotnet50 , you’ll invoke a specific version of .NET. But choosing a different alias is incompatible with most tutorials and examples as they expect a dotnet command to be available.

Export the install location

The DOTNET_ROOT environment variable is often used by tools to determine where .NET is installed. When .NET is installed through Snap, this environment variable isn’t configured. You should configure the DOTNET_ROOT environment variable in your profile. The path to the snap uses the following format: /snap//current . For example, if you installed the dotnet-sdk snap, use the following command to set the environment variable to where .NET is located:

The preceding export command only sets the environment variable for the terminal session in which it was run.

You can edit your shell profile to permanently add the commands. There are a number of different shells available for Linux and each has a different profile. For example:

Bash Shell:

/.bashrc
Korn Shell:

/.kshrc or .profile
Z Shell:

Edit the appropriate source file for your shell and add export DOTNET_ROOT=/snap/dotnet-sdk/current .

TLS/SSL Certificate errors

When .NET is installed through Snap, it’s possible that on some distros the .NET TLS/SSL certificates may not be found and you may receive an error during restore :

To resolve this problem, set a few environment variables:

The certificate location will vary by distro. Here are the locations for the distros where the issue has been experienced.

Distribution	Location
Fedora	/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem
OpenSUSE	/etc/ssl/ca-bundle.pem
Solus	/etc/ssl/certs/ca-certificates.crt

Troubles resolving dotnet

It’s common for other apps, such as the OmniSharp extension for Visual Studio Code, to try to resolve the location of the .NET SDK. Typically, this is done by figuring out where the dotnet executable is located. A snap-installed .NET SDK may confuse these apps. When these apps can’t resolve the .NET SDK, you’ll see an error similar to one of the following messages:

• The SDK ‘Microsoft.NET.Sdk’ specified could not be found
• The SDK ‘Microsoft.NET.Sdk.Web’ specified could not be found
• The SDK ‘Microsoft.NET.Sdk.Razor’ specified could not be found

To fix this problem, symlink the snap dotnet executable to the location that the program is looking for. Two common paths the dotnet command is looking for are /usr/local/bin/dotnet and /usr/share/dotnet . For example, to link the current .NET SDK snap package, use the following command:

You can also review these GitHub issues for information about these problems:

The dotnet alias

It’s possible that if you created the dotnet alias for the snap-installed .NET, you’ll have a conflict. Use the snap unalias dotnet command to remove it, and then add a different alias if you want.

Источник