Introduction

Developing C# on Linux is no longer a workaround. Modern .NET gives Linux developers a first-class toolchain for building command-line tools, web APIs, worker services, and test suites without depending on Windows.

The productive setup is straightforward: install the .NET SDK, choose an editor such as VS Code or Rider, and use the dotnet CLI for project creation, builds, tests, and publishing. Once that workflow is in place, Linux becomes just another supported .NET environment instead of a special case.

Install the .NET SDK

The .NET SDK is the piece you need for development. Installing only the runtime is not enough because the runtime can execute applications but cannot create or build projects.

On a Debian or Ubuntu based distribution, a typical setup looks like this:

sudo apt-get update
sudo apt-get install -y dotnet-sdk-8.0
dotnet --info

Different Linux distributions use different package sources, so the exact install command may vary, but the verification step is always the same. dotnet --info should report an SDK version, not just runtime information.

Once the SDK is available, create a sample application:

dotnet new console -n HelloLinux
cd HelloLinux
dotnet run

That command creates a full working project, restores dependencies, compiles it, and runs it. It is the quickest sanity check that the local toolchain is healthy.

Build a Simple C# Program

The default template is fine, but replacing it with a slightly more useful example helps confirm that the compiler, runtime, and platform integration are all working.

1using System.Runtime.InteropServices;
2
3Console.WriteLine("Hello from .NET on Linux");
4Console.WriteLine($"OS: {RuntimeInformation.OSDescription}");
5Console.WriteLine($"Framework: {RuntimeInformation.FrameworkDescription}");
6Console.WriteLine($"Process architecture: {RuntimeInformation.ProcessArchitecture}");

Run it with:

dotnet run

This is intentionally small, but it exercises the normal edit-build-run loop you will use for larger applications. From here you can switch templates with dotnet new webapi, dotnet new classlib, or dotnet new worker depending on the kind of software you are building.

Use Linux-Friendly Tooling

The dotnet CLI does most of the heavy lifting, so your editor mainly handles navigation, debugging, and refactoring. Two common choices on Linux are:

• VS Code with the C# extension or C# Dev Kit
• JetBrains Rider for a fuller IDE experience

If you use VS Code, open the project folder rather than a single file so the editor can detect the .csproj file and load the workspace correctly. For everyday development, these commands cover most tasks:

1dotnet restore
2dotnet build
3dotnet test
4dotnet publish -c Release -r linux-x64 --self-contained false

dotnet restore fetches NuGet packages, dotnet build compiles the code, dotnet test runs the test suite, and dotnet publish prepares a distributable build. Linux works especially well with this CLI-driven workflow because it is easy to automate in shells, containers, and CI pipelines.

Debugging and Dependencies

Most managed .NET code behaves the same on Linux as it does on other platforms, but native dependencies still matter. If your application uses image libraries, database drivers with native bindings, or platform-specific tooling, verify those packages support Linux as a target environment.

It is also a good habit to add tests early:

1cd ..
2dotnet new xunit -n HelloLinux.Tests
3cd HelloLinux.Tests
4dotnet add reference ../HelloLinux/HelloLinux.csproj
5dotnet test

This makes Linux-specific issues show up sooner, especially when file paths, permissions, or external commands behave differently from a Windows development machine.

Common Pitfalls

The most common setup mistake is installing the runtime instead of the SDK. If dotnet --info does not show an SDK, project creation and builds will fail even though dotnet exists on the system.

Case sensitivity is another trap. Linux filesystems usually treat Data.json and data.json as different files, so code that worked on a case-insensitive machine can break after deployment.

Path handling also causes avoidable bugs. Use Path.Combine and related .NET APIs instead of manually concatenating strings with hard-coded separators.

Finally, watch for native library assumptions. A NuGet package may compile correctly but still fail at runtime if it expects a system package that is not installed on the Linux host.

Summary

• Install the .NET SDK, not just the runtime.
• Use dotnet new, dotnet run, dotnet build, and dotnet test as the core Linux workflow.
• Pick an editor that understands the project file and debugger integration.
• Expect Linux differences around file casing, permissions, and native dependencies.
• Treat the CLI as the stable foundation of C# development on Linux.