Writing C# code needs two things on your machine: the .NET SDK (compiler, runtime, and the dotnet command-line tool, all in one install) and an editor that understands C#. This lesson walks through installing the SDK on Windows, macOS, and Linux, picking an editor, and running a one-command "Hello, cart!" project to prove it all works. The _First C# Program_ lesson picks up from there.

The whole process is short. Install the SDK, pick an editor, create a project with dotnet new console, run it with dotnet run, and read the output. Everything else in this lesson is the details for each OS.

The diagram is the whole chapter in five boxes. The rest of this lesson covers making sure each box happens correctly on your specific OS.

The .NET SDK (Software Development Kit) is what you install to write and run C# code. One download gives you three things bundled together:

You don't install these separately. The SDK is the one package that contains all of them.

This course uses .NET 8, which is the current LTS release. LTS stands for Long-Term Support, meaning Microsoft ships security and bug fixes for it for three years. Non-LTS releases (.NET 7, .NET 9) get only 18 months of support, so production systems and most tutorials stick to LTS versions. If you install something newer, like .NET 9 or .NET 10, the examples in this course still work, but the version numbers in your terminal output will differ.

Windows users have two reasonable paths to the SDK. Pick whichever fits how you already work.

Option 1: the official installer. Visit https://dotnet.microsoft.com/download, pick the .NET 8 (LTS) SDK for Windows, and choose your architecture. For most machines that's x64. ARM-based Windows laptops (Surface Pro X, some Copilot+ PCs) need the arm64 build.

Run the downloaded .exe, click through the installer, and that's it. The installer adds dotnet to your PATH, so any new terminal window can find it.

Option 2: `winget`. If you're comfortable in PowerShell, the Windows Package Manager handles it in one line:

Either way, close any PowerShell windows that were open before the install (they still have the old PATH), then open a fresh one and verify:

The exact patch number varies depending on when you installed, but it should start with 8.0.

On macOS, the official installer is the simplest path, and Homebrew is the cleanest path if you already use it.

Option 1: the official installer. Go to https://dotnet.microsoft.com/download and download the .NET 8 (LTS) SDK for macOS. Pick Arm64 if your Mac has an Apple Silicon chip (M1, M2, M3, M4) or x64 for older Intel Macs. Run the downloaded .pkg and follow the prompts.

Option 2: Homebrew. If Homebrew is already set up, one command does it:

Either path puts dotnet on your PATH. Open a new terminal window and verify:

If you have an older .NET version installed too, that's fine, dotnet picks the newest one by default. The _First C# Program_ lesson explains how global.json pins a project to a specific version when you need that.

On Linux, your package manager handles it, but the package name and command vary by distribution.

Ubuntu and Debian:

On older Ubuntu releases (22.04 and earlier), dotnet-sdk-8.0 isn't in the default repos, and you'll need to add Microsoft's package feed first. The Microsoft docs at https://learn.microsoft.com/dotnet/core/install/linux list the exact commands per Ubuntu version.

Fedora, RHEL, and CentOS Stream:

Arch Linux:

After the install finishes, verify it:

If dotnet says "command not found" right after a successful install, your shell probably needs a new terminal session, or PATH doesn't include /usr/share/dotnet. The Troubleshooting section at the end covers the fix.

Once the SDK is installed, you can technically write C# in any text editor and use dotnet from the terminal to build and run. That's enough for the early lessons in this course. But most C# developers use an editor that understands C#, so it can autocomplete types, surface errors as you type, and jump you to definitions.

Four options cover most needs.

For this course, VS Code with the C# Dev Kit is the recommended starting point. It's free, runs on every OS, and the setup is two steps. Visual Studio Community is excellent if you're on Windows and want the full IDE experience, especially later when you start building web or desktop apps. Rider is great but costs money once your student license runs out. The CLI-only path works too, especially if you already have a favorite editor.

Setting Up VS Code for C#

Step 1: install VS Code from https://code.visualstudio.com/. Same installer on all three OSes, takes a minute.

Step 2: install the C# Dev Kit extension. Open VS Code, click the Extensions icon in the left sidebar (or hit Cmd+Shift+X / Ctrl+Shift+X), search for "C# Dev Kit" by Microsoft, and click Install. The Dev Kit bundles the C# language server, debugger, test runner, and a solution explorer that mirrors what Visual Studio shows.

Step 3: open a folder. File > Open Folder, pick any folder on disk (we'll create one in the _Your First Project_ section below), and VS Code is ready. The C# panel on the sidebar shows your projects and tests once a .csproj exists in the folder.

That's the full editor setup. No SDK configuration in VS Code itself, the Dev Kit picks up whatever dotnet --version reports.

Time to prove the whole chain works. Open a terminal anywhere on your machine. We'll make a folder, generate a console app, and run it.

The dotnet new console command creates a small project from the built-in console template. After it runs, the folder looks like this:

Program.cs is your source file. hello-cart.csproj is the project file (it tells the SDK which .NET version to target and which packages to reference). obj/ is a scratch directory the build tool uses, you don't touch it by hand.

Now run the project:

The first time you run this, the SDK restores any dependencies, compiles the code, and then executes it. Subsequent runs skip the restore unless something changed.

That output came from the default Program.cs the template generated. The whole file is one line of code:

This is top-level statements, a C# feature that lets short programs skip the class Program { static void Main() { ... } } ceremony. The _First C# Program_ lesson opens up Program.cs and explains what every part of that one line is doing, including why Console.WriteLine works without an explicit using System; directive.

If you'd like to confirm you can edit and re-run, open Program.cs in your editor and change the string to "Hello, cart!". Save, then back in the terminal:

If you see that, your environment works. The SDK, the editor, the CLI, and the runtime are all wired up.

You used three CLI commands above. The table below covers a dozen more for working on real projects.

dotnet --info is the one to remember. When something's wrong, run it first, because it shows the SDK version, the runtimes installed alongside it, and the architecture (x64 vs arm64). Most "it works on my machine" puzzles get solved by comparing dotnet --info output between two machines.

Most setup problems come from one of three things. Knowing the shape of each one saves an hour.

Problem 1: `dotnet` command not found.

You ran the installer, but dotnet --version says the command doesn't exist.

Two likely causes. The terminal window was open before the installer added dotnet to PATH, so close it and open a new one. Or the installer didn't update PATH at all, which happens on some Linux setups. Run which dotnet (macOS/Linux) or where dotnet (Windows) to see whether the binary is on PATH. If it's not, the Microsoft install docs at https://learn.microsoft.com/dotnet/core/install/ have the exact PATH lines per OS and shell.

On macOS, the SDK lives at /usr/local/share/dotnet/dotnet. On Linux it's typically /usr/share/dotnet/dotnet. On Windows it's C:\Program Files\dotnet\dotnet.exe.

Problem 2: SDK version mismatch.

You run dotnet --version and get a number you didn't expect, or a project refuses to build with a message about a missing SDK.

This usually means more than one SDK is installed and the dotnet command is resolving to one you didn't intend, or a project pins a specific SDK version through a global.json file. Run:

The output lists every SDK and runtime installed on your machine. If the SDK list is empty or missing 8.0, reinstall. If a project has a global.json in its folder (or any parent folder), dotnet honors it and uses the SDK version listed there. Open global.json, check the version field, and either install that SDK or update the file to a version you have.

Problem 3: Permission denied on Linux.

You try to run a CLI command and Linux refuses with "Permission denied".

This is usually about file permissions on a project folder or the SDK binary itself, not about the install. If a folder was created with sudo, its files belong to root and your normal user can't write to them. Fix the ownership:

If dotnet itself reports a permission error during install, it usually means you used sudo correctly and then opened a terminal as a different user. Run dotnet --info to see which SDK the current user can see.