Install C# and .NET on Linux: SDK, editor and first console project

Choose a supported release

Check the official .NET support policy and the installation page for your operating system before downloading. Choose a supported Long Term Support (LTS) SDK for a new learning project unless an existing project specifies another supported target. Use the newest patch for that release line. Do not treat a preview build or an end-of-support version as the default beginner choice.

At the 21 October 2026 review, .NET 10 is the supported LTS line recommended here; .NET 8 and 9 are also listed as supported but approach their November 2026 end-of-support dates. The example package name dotnet-sdk-10.0 in the Linux guide is tied to this review date. Recheck the support policy and your distribution’s package page before installing later. The SDK version you install, the target framework chosen by a project, and the runtime required to launch its output are related but not identical choices.

SDK or runtime: which do you need?

Install the .NET SDK if you want to write, build or run your own C# projects. It supplies the dotnet CLI, project templates and build tools, and includes a corresponding runtime. A runtime-only installation can execute a compatible framework-dependent app, but it does not supply the tools needed for dotnet new or dotnet build.

For a deployed app, the required runtime depends on how that app was published. A console app can use the .NET Runtime; an ASP.NET Core app needs the ASP.NET Core Runtime, which includes the base .NET Runtime. A self-contained deployment bundles what it needs instead of relying on a separately installed shared runtime. For these learning guides, select the SDK download or SDK package, not a runtime-only option.

Identify your distribution and architecture

Linux instructions depend on the distribution, its release and its package feed. Read /etc/os-release to identify the distribution and version, and uname -m to identify the CPU architecture. Compare both with Microsoft’s Linux installation index and your distribution-specific page before running any package command.

Prefer the documented package source for your distribution. A supported Ubuntu package may come from Ubuntu’s own feed, a .NET backports feed or a Microsoft feed depending on the release. Debian commonly uses Microsoft’s repository registration package; Fedora uses dnf packages. Mixing .NET packages from several feeds can break runtime resolution, so do not add a second source merely because a package name looks familiar.

Shell — identify distribution and CPU

cat /etc/os-release
uname -m

Choose the instructions for your distribution

The table gives a starting path verified against Microsoft’s installation pages on 21 October 2026. It is not a universal command list: check the linked distro page for supported release numbers, architectures and any newer package-source decision before installing. The dotnet-sdk-10.0 commands below refer to the supported .NET 10 LTS line at this review.

Ubuntu 24.04 offers .NET 10 through its built-in feed. Ubuntu 22.04 uses the Ubuntu .NET backports feed for .NET 10. On Debian 12 or 13, use the matching Microsoft repository package for that Debian release before apt installing. On currently supported Fedora releases, use Fedora’s dnf package instructions. If you use a different distribution, follow its entry in the Linux installation index rather than assuming an apt or dnf command will work.

Distribution	Package source for the example	Next step
Ubuntu 24.04	Built-in Ubuntu feed	Run the Ubuntu 24.04 apt command below.
Ubuntu 22.04	Ubuntu .NET backports feed	Register backports, then run apt.
Debian 12 or 13	Matching Microsoft Debian package feed	Register the repository for your Debian release, then run apt.
Fedora	Fedora package repositories	Follow the supported-release table, then run dnf.

Install the SDK with your package manager

Run only the command group for your distribution. On Ubuntu 22.04, install software-properties-common first if add-apt-repository is missing. For Debian, the example repository URL below is for Debian 13; use /debian/12/ instead if /etc/os-release reports Debian 12. Inspect an existing packages-microsoft-prod registration before adding a second copy.

Use your package manager’s normal update process for later security and patch updates. If dotnet-sdk-10.0 is unavailable, do not silently switch to an unsupported package: check the release matrix, enabled repository and architecture on the official distribution page.

Ubuntu 24.04 — built-in Ubuntu feed

sudo apt-get update
sudo apt-get install -y dotnet-sdk-10.0

Ubuntu 22.04 — register Ubuntu .NET backports, then install

sudo add-apt-repository ppa:dotnet/backports
sudo apt-get update
sudo apt-get install -y dotnet-sdk-10.0

Debian 13 — register the matching Microsoft feed, then install

wget https://packages.microsoft.com/config/debian/13/packages-microsoft-prod.deb
sudo dpkg -i packages-microsoft-prod.deb
sudo apt-get update
sudo apt-get install -y dotnet-sdk-10.0

Fedora — install from the supported Fedora package feed

sudo dnf install dotnet-sdk-10.0

Verify SDK and runtime versions

dotnet --list-sdks confirms the development kit; dotnet --list-runtimes lists the installed shared runtimes. dotnet --info reports architecture and installation paths. command -v dotnet reveals which executable the shell finds. If you only see a runtime and no SDK, dotnet new and dotnet build will not work.

On apt-based systems, apt-cache policy dotnet-sdk-10.0 can show which enabled repository provides the package. This helps identify an unexpected source before you install or upgrade.

Shell — inspect the installation

dotnet --list-sdks
dotnet --list-runtimes
dotnet --info
command -v dotnet

Ubuntu or Debian — inspect the package source when needed

apt-cache policy dotnet-sdk-10.0

Common Linux setup problems

If apt or dnf cannot find the SDK package, confirm the distribution release, enabled package source and architecture against its official installation page. Do not add an unrelated repository or copy commands for another release. On Ubuntu, check whether you should use the built-in feed or the documented backports feed.

If dotnet --list-sdks is empty, you may have installed only a runtime. If dotnet --info reports missing host files, libhostfxr.so or framework lists after installing from different repositories, read Microsoft’s package-mix-up guide and resolve the feed choice deliberately. If dotnet run cannot find a project, enter the folder containing HelloCSharp.csproj first.

For WSL, run these Linux commands inside your WSL distribution and follow that distribution’s package instructions. A Windows SDK installation does not automatically become a Linux SDK inside WSL.

Create and run a first project

After verifying the SDK, open a terminal in a folder where you can create files. The first command creates a new console project with Program.cs and a project file. Change into that folder, replace Program.cs with the example below, save it, then run the project. dotnet run builds the project if needed and prints the output in the terminal.

The example is a small top-level C# program, supported by modern .NET console templates. Console.WriteLine writes one line of text. If your editor still shows the template’s Hello, World! output, confirm that you saved the correct Program.cs before running again.

Terminal — create and enter a console project

dotnet new console -n HelloCSharp
cd HelloCSharp

Terminal — after replacing and saving Program.cs

dotnet run

Syntax

dotnet --list-sdks

Examples

Program.cs: a first console program

Replace the generated Program.cs with this line, then run dotnet run in the project folder. Expected output: Hello from C#!

Console.WriteLine("Hello from C#!");

The quoted characters form a string containing the message. The quotes are part of C# syntax and are not printed.
Console is a .NET library class. Its WriteLine method writes the string to standard output and then starts a new line; the terminal displays that output.
The semicolon ends the statement. Save Program.cs, run dotnet run from the folder containing the project file, and change the message to check that your edits take effect.

Best practices

Choose a currently supported SDK from the official .NET site or the supported package source for your operating system.
Check dotnet --list-sdks before creating a project; a runtime-only installation is not enough to build C# source.
Keep your practice project in its own writable folder and run dotnet run from the folder containing its project file.
Follow your organisation’s approved installation process on a managed computer.

Runtime & versions

.NET runtime. Feature availability depends on the language and runtime version used by your project; consult the official reference below.

C# language reference