Install .NET 9 SDK on Rocky Linux 10 / AlmaLinux 10 [Guide]

.NET 10 is the latest Long Term Support (LTS) release from Microsoft, supported until November 2028. On Rocky Linux 10 and AlmaLinux 10, installing .NET is straightforward since the SDK and runtime packages ship in the default AppStream repositories. No third-party repos needed.

Original content from computingforgeeks.com - post 2067

This guide covers installing the .NET 10 SDK and runtime on Rocky Linux 10 and AlmaLinux 10, verifying the installation, creating and running a sample application, publishing for production deployment, and managing multiple SDK versions side by side.

Prerequisites

Before getting started, make sure you have the following in place:

A running Rocky Linux 10 or AlmaLinux 10 system
A user account with sudo privileges (or root access)
An active internet connection for downloading packages

Start by updating your system packages to the latest available versions:

sudo dnf update -y

Step 1: Install .NET 10 SDK on Rocky Linux 10 / AlmaLinux 10

The .NET SDK includes everything you need to build, test, and run .NET applications. It bundles the runtime, the compiler, and the dotnet CLI tool. If you plan to develop .NET apps on this machine, install the SDK.

The package is available directly from the AppStream repository, so no additional repo configuration is required:

sudo dnf install -y dotnet-sdk-10.0

This pulls in all required dependencies including the .NET runtime, ASP.NET Core runtime, host components, and native libraries like libicu and openssl-libs.

Once the installation finishes, confirm the SDK version:

dotnet --version

You should see the installed SDK version number returned:

10.0.105

For a detailed view of all installed SDKs and runtimes, run:

dotnet --info

This displays the SDK version, runtime versions, OS platform, and the base path where .NET components are installed.

Step 2: Install .NET Runtime Only (Without the SDK)

On production servers that only need to run pre-built .NET applications, you can install just the runtime without the full SDK. This keeps the footprint smaller and reduces the attack surface.

There are two runtime packages available:

ASP.NET Core Runtime – includes both the base .NET runtime and the ASP.NET Core runtime. This is the best choice for web applications and APIs:

sudo dnf install -y aspnetcore-runtime-10.0

.NET Runtime – the base runtime only, without ASP.NET Core support. Use this for console applications and background services that do not serve HTTP traffic:

sudo dnf install -y dotnet-runtime-10.0

For most production deployments running web workloads, go with aspnetcore-runtime-10.0 since it covers both scenarios.

Step 3: Verify the .NET Installation

After installing either the SDK or runtime, verify that the dotnet command is available and working correctly.

List all installed SDKs:

dotnet --list-sdks

The output confirms the SDK version and its installation path:

10.0.105 [/usr/lib64/dotnet/sdk]

List all installed runtimes:

dotnet --list-runtimes

You should see the .NET runtime and ASP.NET Core runtime entries:

Microsoft.AspNetCore.App 10.0.5 [/usr/lib64/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 10.0.5 [/usr/lib64/dotnet/shared/Microsoft.NETCore.App]

Step 4: Create and Run a Hello World Application

The fastest way to confirm everything works end-to-end is to create a simple console application, build it, and run it.

Create a new console application in a directory called helloworld:

dotnet new console -n helloworld

The scaffolding output confirms the project was created successfully:

The template "Console App" was created successfully.

Processing post-creation actions...
Restoring /home/jkmutai/helloworld/helloworld.csproj:
  Determining projects to restore...
  Restored /home/jkmutai/helloworld/helloworld.csproj (in 85 ms).
Restore succeeded.

Switch into the project directory and run the application:

cd helloworld
dotnet run

You should see the default output:

Hello, World!

That confirms the compiler, runtime, and project system are all functioning correctly.

Step 5: Create and Run an ASP.NET Core Web Application

For web developers, here is how to scaffold and run a basic ASP.NET Core web app. Create a new web project:

dotnet new webapp -n mywebapp

Move into the project directory and start the development server:

cd mywebapp
dotnet run

The output shows the URLs where the application is listening:

Building...
info: Microsoft.Hosting.Lifetime[14]
      Now listening on: http://localhost:5000
info: Microsoft.Hosting.Lifetime[0]
      Application started. Press Ctrl+C to shut down.

If you need the app to listen on all interfaces (useful for testing from another machine), set the URL binding explicitly:

dotnet run --urls "http://0.0.0.0:5000"

Open TCP port 5000 in the firewall to allow external access during development:

sudo firewall-cmd --add-port=5000/tcp --permanent
sudo firewall-cmd --reload

You can then access the web application at http://your-server-ip:5000 from a browser.

Step 6: Publish a .NET Application for Production

During development, dotnet run compiles and runs in one step, but production deployments need a published build. Publishing produces optimized output ready for deployment.

Framework-Dependent Deployment (FDD)

This is the default and most common approach. The published output requires the .NET runtime to be installed on the target server. From your project directory, run:

dotnet publish -c Release -o ./publish

The compiled application files are placed in the ./publish directory. Run the published build to verify it works:

dotnet ./publish/helloworld.dll

The output confirms the published build runs correctly:

Hello, World!

Self-Contained Deployment (SCD)

A self-contained deployment bundles the .NET runtime with your application. The target server does not need .NET installed at all. This is useful when you cannot control the server environment:

dotnet publish -c Release --self-contained -r linux-x64 -o ./publish-scd

The -r linux-x64 flag specifies the target runtime identifier. The output directory will contain a standalone executable:

./publish-scd/helloworld

Self-contained builds are larger (around 60-80 MB) since they include the entire runtime, but they eliminate dependency management on the deployment target.

Running as a systemd Service

For production web applications, run the app as a systemd service so it starts automatically on boot and restarts on failure. Create a service unit file:

sudo vi /etc/systemd/system/mywebapp.service

Add the following configuration (adjust paths to match your deployment):

[Unit]
Description=My .NET Web Application
After=network.target

[Service]
WorkingDirectory=/opt/mywebapp
ExecStart=/usr/bin/dotnet /opt/mywebapp/mywebapp.dll
Restart=always
RestartSec=10
SyslogIdentifier=mywebapp
User=www-data
Environment=ASPNETCORE_ENVIRONMENT=Production
Environment=DOTNET_PRINT_TELEMETRY_MESSAGE=false

[Install]
WantedBy=multi-user.target

Create the service user if it does not exist, then enable and start the service:

sudo useradd -r -s /sbin/nologin www-data 2>/dev/null
sudo systemctl daemon-reload
sudo systemctl enable --now mywebapp.service

Check that the service is running:

sudo systemctl status mywebapp.service

The service should show active (running) in the output.

Step 7: Install Multiple .NET SDK Versions Side by Side

.NET supports running multiple SDK and runtime versions on the same machine. This is common in environments where different projects target different .NET versions.

Install .NET 9 SDK alongside .NET 10:

sudo dnf install -y dotnet-sdk-9.0

Install .NET 8 SDK as well if needed:

sudo dnf install -y dotnet-sdk-8.0

Verify all installed SDKs with:

dotnet --list-sdks

All three versions appear in the output:

8.0.115 [/usr/lib64/dotnet/sdk]
9.0.114 [/usr/lib64/dotnet/sdk]
10.0.105 [/usr/lib64/dotnet/sdk]

By default, the dotnet command uses the latest SDK installed. To pin a specific SDK version for a project, create a global.json file in the project root:

dotnet new globaljson --sdk-version 9.0.114

This creates a global.json file that locks the project to the specified SDK version. Any dotnet commands run from that directory will use .NET 9 instead of the latest installed version.

Verify the active SDK for the current directory:

dotnet --version

The output reflects the pinned version:

9.0.114

Uninstall .NET from Rocky Linux 10 / AlmaLinux 10

To remove .NET completely from your system, uninstall the SDK and runtime packages:

sudo dnf remove -y dotnet-sdk-10.0 aspnetcore-runtime-10.0 dotnet-runtime-10.0

To remove a specific older version while keeping the current one:

sudo dnf remove -y dotnet-sdk-9.0

Troubleshooting Common Issues

dotnet command not found after installation

If the dotnet command is not found after installing the SDK, the binary path may not be in your shell’s PATH. Check where it is installed:

rpm -ql dotnet-sdk-10.0 | grep "dotnet$"

On RHEL-based systems, the binary is typically at /usr/lib64/dotnet/dotnet with a symlink at /usr/bin/dotnet. If the symlink is missing, create it manually:

sudo ln -s /usr/lib64/dotnet/dotnet /usr/bin/dotnet

ICU library errors

If you see errors about missing ICU libraries (used for globalization support), install the libicu package explicitly:

sudo dnf install -y libicu

Alternatively, if you do not need full globalization support, you can run .NET in invariant globalization mode by setting an environment variable:

export DOTNET_SYSTEM_GLOBALIZATION_INVARIANT=1

SDK and runtime version mismatch

If you get errors about incompatible framework versions when running an application, check what is installed and what the project targets:

dotnet --info

Then compare with the target framework in your project’s .csproj file. The TargetFramework value (e.g., net10.0) must match an installed runtime version.

Conclusion

.NET 10 installs cleanly on Rocky Linux 10 and AlmaLinux 10 from the default AppStream repositories with a single dnf install command. The SDK is for development machines, while production servers only need the runtime. Multiple .NET versions can coexist on the same system, and you can pin specific versions per project using global.json.

For more details, refer to the official Microsoft .NET on RHEL documentation and the .NET 10 download page.