How to Check Installed .NET and .NET Framework Versions

Quick Answer

For modern .NET, including .NET Core and .NET 5 or later, open Command Prompt or PowerShell on Windows, or Terminal on Linux or macOS. Run these commands to list installed software development kits (SDKs) and runtimes:

dotnet --list-sdks
dotnet --list-runtimes

For .NET Framework 4.5 or later on Windows, read the registry’s Release value with PowerShell and compare the decimal result with the version table below. Modern .NET and .NET Framework require separate checks.

Get-ItemPropertyValue -LiteralPath 'HKLM:\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full' -Name Release

Choose the Correct Check

Component	Purpose	What to check
.NET SDK	Tools for building .NET applications	Installed SDK versions
.NET runtime	Components for running .NET applications	Runtime family, version, and architecture
.NET Framework	A separate Windows application platform	Framework registry entries

The command-line checks below normally work without administrator or root privileges. Registry Editor may request administrator credentials. These procedures only inspect information; no configuration changes or rollback are required.

Check Modern .NET SDKs and Runtimes

List Installed SDKs

Run this command in your operating system’s terminal:

dotnet --list-sdks

Each output line identifies an SDK version and its installation directory. An SDK includes the corresponding runtime, but installing a runtime alone does not provide the SDK.

If no SDK entries appear, the invoked .NET installation has no SDKs to report. Runtimes may still be present.

List Installed Runtimes

dotnet --list-runtimes

Each line shows a runtime family, version, and directory. Interpret the runtime names as follows:

Runtime name	Purpose
Microsoft.NETCore.App	Base runtime for modern .NET applications
Microsoft.WindowsDesktop.App	Windows desktop applications using Windows Forms or Windows Presentation Foundation (WPF)
Microsoft.AspNetCore.App	ASP.NET Core web applications

When investigating a missing-runtime error, match the runtime family as well as the version. The base runtime alone does not supply the Windows Desktop runtime.

Display Environment and Installation Details

dotnet --info

Use this output to inspect SDK and runtime details, installation paths, operating-system information, and host architecture.

To display the SDK selected for the current working directory, use:

dotnet --version

This returns one SDK version, not an inventory of installed runtimes. A project’s global.json file can influence SDK selection.

Check Architecture and Installation Location

The lists normally reflect the architecture of the invoked executable: an x86 executable lists x86 installations, while an x64 executable lists x64 installations. A single check should not be treated as a complete inventory of every architecture or custom installation.

On Windows, run the following in Command Prompt or PowerShell to locate matching executables in the current directory and PATH:

where.exe dotnet

On a typical x64 Windows installation, you can query the standard x64 and x86 locations explicitly. Run these PowerShell commands only if the corresponding files exist:

& 'C:\Program Files\dotnet\dotnet.exe' --list-runtimes
& 'C:\Program Files (x86)\dotnet\dotnet.exe' --list-runtimes

Custom installations and Arm64 systems can use different locations. Use the executable appropriate to the application’s architecture.

Check .NET Framework on Windows

Read the Release Value with PowerShell

For .NET Framework 4.5 and later, use the Quick Answer command. It returns a decimal number. Match the highest threshold your result meets:

.NET Framework version or later	Minimum Release value, decimal
4.8.1	533320
4.8	528040
4.7.2	461808
4.7.1	461308
4.7	460798
4.6.2	394802
4.6.1	394254
4.6	393295
4.5.2	379893
4.5.1	378675
4.5	378389

These are minimum thresholds, not every possible exact value. For example, 528040, 528049, 528372, and 528449 identify .NET Framework 4.8 on different Windows releases. Compare unfamiliar values with Microsoft’s full detection table.

Query the Registry from Command Prompt

Run this read-only command in Command Prompt or PowerShell:

reg query "HKLM\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full" /v Release

The /v parameter selects one registry value. Registry DWORD output commonly appears in hexadecimal, starting with 0x; use the PowerShell method for a decimal result before comparing it with the table.

To inspect the broader Framework installation records, including older versions:

reg query "HKLM\SOFTWARE\Microsoft\NET Framework Setup\NDP" /s

The /s parameter includes subkeys. A key name alone is not sufficient proof of installation. For older Framework releases, consult the applicable Install and Version entries and Microsoft’s detection guidance.

Use Registry Editor

1. Open Registry Editor from the Start menu and approve the administrator prompt if required.
2. Navigate to the following location:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full

3. Locate Release.
4. If necessary, double-click it and select Decimal to read the value. Do not change the value data; select Cancel afterward.
5. Compare the number with the table above.

Framework 4.5 and later remain under v4\Full. Do not expect separate v4.5 or v4.8 registry branches.

Check Installation Folders in File Explorer

Modern .NET

On Windows, common locations include:

• C:\Program Files\dotnet\sdk — SDK version folders.
• C:\Program Files\dotnet\shared — runtime families and version folders.
• C:\Program Files (x86)\dotnet — a common location for x86 installations.

Folder inspection is useful when the command is unavailable, but installations can use custom paths. Confirm results with the executable from the relevant installation whenever possible.

.NET Framework

Typical Windows locations are:

C:\Windows\Microsoft.NET\Framework
C:\Windows\Microsoft.NET\Framework64

Adjust the Windows directory if necessary. The v4.0.30319 folder does not prove that only .NET Framework 4.0 is installed. Later Framework 4.x releases use the same CLR generation. The common language runtime (CLR), which executes managed code, has its own version numbering.

Use the registry Release value to identify Framework 4.5 or later. Folder names cannot distinguish releases such as 4.7.2, 4.8, and 4.8.1 reliably.

Troubleshoot Missing or Unexpected Results

The dotnet Command Is Not Recognized

This can mean .NET is absent or its executable is outside PATH, the list of directories searched for commands. Open a new terminal if installation just completed, then inspect the installation folders or query the executable by its full path.

For Linux and macOS, installation paths depend on the installation method. Microsoft’s installation-detection documentation lists common locations.

A Framework Registry Key or Value Is Missing

Check the spelling first: the registry key is NET Framework Setup, without a leading period. A missing Release value means Framework 4.5 or later was not detected through that query; it does not rule out older Framework versions.

If results differ between tools on 64-bit Windows, compare the two registry views:

reg query "HKLM\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full" /v Release /reg:32
reg query "HKLM\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full" /v Release /reg:64

The final parameter explicitly selects the registry view. An access-denied result is a permissions issue, not evidence that the software is missing.

An Application Still Reports a Missing Runtime

• Confirm whether it requires modern .NET or .NET Framework.
• Compare the requested runtime family, version, and architecture with the detected installation.
• Do not assume that a newer modern .NET major version satisfies an older application’s requirements. Runtime selection depends on the application’s configuration and roll-forward rules.
• For build failures, check the required SDK and any global.json file. A working runtime does not establish that the required SDK is available.

Verify Your Findings

A successful check produces SDK or runtime version entries, or a Framework Release number that maps to Microsoft’s documentation. Record the installation path and architecture alongside the version when troubleshooting.

If you subsequently install a required component, reopen the terminal, repeat the relevant check, and retry the original application or build. Detection confirms that a component is present; successful application startup or a successful build confirms that the original requirement is satisfied.

Frequently Asked Questions

Can multiple .NET versions be installed together?

Modern .NET supports side-by-side installations. Framework 4.x releases follow an in-place update model, so they should not be interpreted as independent installations of every earlier 4.x release.

Why does an application run when no shared runtime is listed?

It may be a self-contained deployment that includes its own runtime. An application published using Native AOT can also run without a separately installed .NET runtime. Shared-runtime commands do not inventory every application’s bundled components.

Does finding a version mean it is still supported?

No. Installation detection reports presence, not support status or security-update compliance. Check Microsoft’s lifecycle guidance before selecting a version for deployment.

Sources

• Microsoft Learn: Check installed .NET versions on Windows, Linux, and macOS
• Microsoft Learn: dotnet command reference
• Microsoft Learn: Determine which .NET Framework versions are installed
• Microsoft Learn: .NET Framework versions and dependencies
• Microsoft Learn: Registry query command reference
• Microsoft Learn: Install .NET on Windows and troubleshoot installation detection
• Microsoft Learn: Select which .NET version to use
• Microsoft Learn: .NET application publishing overview