Alright, let's talk about something that seems simple but trips up so many developers – how to check which version of .NET runtime you've got running on your Linux machine. I remember spending half an hour on this when I first switched from Windows to Linux for .NET development. The terminal felt like a different planet back then.

Why Bother Checking .NET Version on Linux?

So picture this: you're deploying a .NET 6 app to your Ubuntu server, but it crashes with some cryptic error. Your local machine runs fine, but production fails. Sound familiar? That's when you need to check the .NET runtime version ASAP. Compatibility issues between framework versions cause more headaches than missing semicolons, I swear.

Here's why you'll constantly need these linux commands to check .net runtime version:

• Debugging nightmares – When your app throws "Could not load file or assembly" errors because the runtime mismatch
• Deployment prep – Verifying server environments before pushing code
• Security patching – Checking if you're vulnerable to that new CVE everyone's panicking about
• Multi-project solutions – When different microservices require different .NET versions on the same machine

Honestly, not knowing these commands is like cooking without tasting your food. You'll eventually get burned.

Before We Start: The Essentials

Quick reality check – you need to have .NET actually installed first. Sounds obvious? You'd be surprised how many times I've seen people trying to run dotnet commands on a fresh VM with zero SDK installed.

curl -sSL https://dot.net/v1/dotnet-install.sh | bash

sudo apt-get install dotnet-sdk-6.0

Method 1: dotnet --info (The Go-To)

This is the golden standard when you need to check .net runtime version on linux. Just pop this into your terminal:

What you'll get is a beautiful wall of text that tells you everything:

.NET SDK:
 Version:           6.0.408
 Commit:            9c1e4b0a3e

Runtime Environment:
 OS Name:     Ubuntu
 OS Version:  20.04
 OS Platform: Linux
 RID:         ubuntu.20.04-x64
 Base Path:   /usr/share/dotnet/sdk/6.0.408/

Host (useful for support):
  Version:      6.0.16
  Architecture: x64
  Commit:       7a1bb16787

.NET SDKs installed:
  6.0.408 [/usr/share/dotnet/sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 6.0.16 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 6.0.16 [/usr/share/dotnet/shared/Microsoft.NETCore.App]

See that last line? That's your runtime version – 6.0.16 in this case. I use this method daily because it gives you both the SDK and runtime versions in one shot. But be warned, the output can be overwhelming if you just need a quick version.

Method 2: The Precise Runtime Check

For times when you only care about the runtime, this command is laser-focused:

Sample output:

Microsoft.AspNetCore.App 6.0.16 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 6.0.16 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 7.0.5 [/usr/share/dotnet/shared/Microsoft.NETCore.App]

Notice how it shows multiple versions? That's why this command rocks – it reveals all installed runtimes. Last week I discovered a server had both .NET 6 and .NET 7 runtimes side-by-side causing conflicts. Saved me hours.

Method 3: The Manual Hunt (No CLI Needed)

What if dotnet isn't installed? Maybe you're on a minimal server or troubleshooting a broken installation. Time to go old-school and check directly in the file system.

The runtimes live in:

/usr/share/dotnet/shared/Microsoft.NETCore.App/

Just list that directory:

You'll see folders like:

6.0.16  7.0.5

Each folder corresponds to an installed runtime version. This saved me when a corrupted dotnet binary prevented --version from working. But honestly, I hate digging through directories like this – feels like archaeology.

Method 4: SDK Version Cross-Check

Sometimes you need to verify SDK versions too:

Output:

6.0.408 [/usr/share/dotnet/sdk]
7.0.302 [/usr/share/dotnet/sdk]

Why bother? Because SDK versions map to runtime capabilities. That 6.0.408 SDK requires at least 6.0.16 runtime. Found this out the hard way when CI builds started failing mysteriously.

Method Comparison: Which Should You Use?

My personal workflow: I start with dotnet --list-runtimes for quick checks, then dotnet --info when I need context. The file system method is my last resort.

Special Scenarios You'll Encounter

Self-Contained Applications Gotcha

Here's something that messed me up early on. When you publish self-contained apps, they embed their own runtime. So system-wide checks won't help! To find the version bundled in your app:

cd /path/to/your/app
./your-app --version

Some apps use different version flags like -v or version. Check your app's docs. I learned this after wasting an hour wondering why my app showed different versions locally vs production.

Docker Containers

Containers add another layer of complexity. To check .NET version inside a running container:

docker exec -it your-container-name dotnet --info

Or if you're building images, stick this in your Dockerfile for clarity:

RUN dotnet --info > /dotnet-version.txt

This creates a version log inside the image. Wish I'd started doing this sooner – would've prevented so many "it works on my machine" conversations.

Global.json Version Locking

Ever seen this error?

Could not execute because the application was not found or a compatible .NET SDK is not installed.

Probably missing a global.json file that pins specific SDK versions. To check if you're affected:

cat global.json

Look for the "version" field. This thing once blocked my team's deployment for two days because someone committed a global.json requiring an SDK version that didn't exist on our build server.

Troubleshooting Common Issues

Let's talk about the ugly stuff – when the linux command to check .net runtime version doesn't behave.

export PATH=$PATH:$HOME/.dotnet

dotnet --version 6.0

sudo ~/.dotnet/dotnet --info

My worst dotnet version mystery? After a distro upgrade, dotnet commands returned empty output. Turned out libicu was missing. Fixed with:

sudo apt install libicu-dev

Advanced Version Management

When you manage multiple projects, you need better tools than basic linux commands to check .net runtime version. Enter:

Dotnet Version Manager (DVM)

This tool is a lifesaver. Install it via:

curl -sSL https://asdf-vm.com/scripts/install.sh | bash
asdf plugin add dotnet-core

Then switch versions effortlessly:

asdf global dotnet-core 6.0.408

Check current version:

asdf current dotnet-core

Why I love it: No more PATH juggling or global.json conflicts. Projects automatically use their pinned versions.

Checking Runtime in CI/CD Pipelines

In GitHub Actions, add this step:

- name: Check .NET version
  run: dotnet --info

For Azure DevOps:

- script: dotnet --info
  displayName: 'Check .NET Version'

Pro move: Fail builds if wrong version detected:

if [[ $(dotnet --version) != "6.0.408" ]]; then
  echo "Wrong .NET version!"
  exit 1
fi

This saved our production deploy when someone accidentally updated a build agent.

Your Burning Questions Answered

How often should I check .NET versions?

Every deployment, without fail. I run a version check script in our CI pipeline that compares runtime versions between environments. Found three mismatches last month alone.

What's the difference between SDK and runtime?

• SDK - Build tools (compiler, CLI)
• Runtime - Execution environment for apps

You can have multiple runtimes with one SDK. But mismatches cause subtle bugs that'll make you question your career choices.

Is there a universal command for all distros?

Mostly yes - dotnet --info works across Ubuntu, CentOS, Fedora, etc. But package paths differ:

Can I check versions without SSH access?

If you're desperate:

• Check Dockerfile FROM tags
• Look at deployment scripts
• Inspect package manifests (dpkg -l | grep dotnet)

But honestly, SSH access is non-negotiable for proper ops work.

Why does my container show different versions?

Probably base image differences. Always specify full tags:

FROM mcr.microsoft.com/dotnet/aspnet:6.0.16

Not just ":6.0" which floats to latest patch. Learned this after a patch update broke our logging.

A Horror Story (And How to Avoid It)

Last year, our payment service crashed on Black Friday. Why? The deployment script pulled "latest" .NET runtime which turned out to be an incompatible minor version. We lost $18k in sales before rolling back.

Now we enforce strict version checks:

1. Pre-deployment script: dotnet --list-runtimes > runtime.txt
2. Compare runtime.txt with approved versions list
3. Automatically block deployments with unapproved versions

Was it overkill? Maybe. But I sleep better now knowing our runtime versions are locked down.

Wrapping It Up

So there you have it – everything I've learned about checking .NET versions on Linux the hard way. Whether you use dotnet --info for comprehensive checks or dotnet --list-runtimes for quick verification, just make sure you're checking consistently. What seems like a trivial task can save you from production nightmares.

Honestly? The biggest lesson isn't about commands. It's about version discipline. Know exactly what's running where, document it, and validate constantly. Your future self will high-five you when deployments just work.

Got a tricky version situation? Hit me up – I've probably fought that dragon before. Happy coding!