.NET Core is an invaluable platform for developers. This open-source development platform, maintained by Microsoft, is used to build cloud-native, cross-platform, and even apps specifically for use on Internet of Things (IoT) devices.
Problems can arise if a developer installs a newer version of .NET Core and then tries to run an older project. There are simple ways to check which .NET Core versions you have installed to prevent problems using the dotnet CLI (command-line interface).
What is the latest version of .Net Core?
The latest versions of .NET core are listed below, along with their release dates:
Understanding .NET core versions
The earliest version of .NET Core dates back to 2016, when it was created primarily to enhance support for cross-platform app development. Since then, there have been multiple versions, with the latest stable release being .NET 8.0, launched in June 2024. The .NET naming convention has shifted to simply ‘.NET’ from version 5 onward, streamlining the brand. Although .NET 8.0 is the most recent, .NET Core 3.1, released in December 2019, remains widely used by many app developers due to its long-term support.
While backward compatibility is a desirable quality in development tools, .NET Core has some limitations. For example, if you install .NET Core version 3.1 and try to run a previous project created using an earlier version, you may encounter an SDK error. SDK stands for software development kit, and without the correct .NET Core SDK installed, you won’t be able to run your older projects. The first step to overcome this issue is to use the dotnet –list-sdks command in the dotnet CLI to discover the .NET Core versions you have installed. Ensuring you have the required SDK for your project is crucial for maintaining compatibility.
.NET Core versioning scheme
The .NET Core versioning scheme follows a structured approach, which is essential for maintaining clarity and consistency across its releases. This scheme is crucial given the platform’s broad use for developing cloud-native, cross-platform, and IoT applications.
Major, minor, patch overview:
- Major version: Incremented annually, this version signals significant product changes, including new features, API-breaking changes, and major dependency updates. Notably, even-numbered major versions like .NET 6 and .NET 8 are long-term supported (LTS), providing three years of support. In contrast, odd-numbered versions receive standard-term support (STS) with 18 months of updates.
- Minor version: Increased when new behaviors or public APIs are introduced, along with non-breaking enhancements, this increment may also reflect the adoption of a newer minor version of an existing dependency.
- Patch version: Adjusted for bug fixes, new platform support, or minor updates in dependencies. It represents maintenance updates that do not alter the API surface area or introduce new features.
The .NET Runtime adheres to semantic versioning (SemVer), denoted as MAJOR.MINOR.PATCH[-PRERELEASE-BUILDNUMBER]. This method ensures each version number clearly communicates the extent and nature of changes, aiding developers in understanding the impact of upgrades.
LTS vs. STS
LTS (Long-Term Support):
Long-Term Support (LTS) versions of .NET Core are designed to provide extended stability and support. These versions are released every two years and offer three years of free support and patches.
LTS versions are typically even-numbered (e.g., .NET 6, .NET 8) and are essential for environments where long-term stability and reliability are critical. LTS versions are often chosen for enterprise applications due to their extended maintenance window, ensuring that applications remain secure and stable without frequent major updates.
Benefits of LTS:
- Stability: Provides a reliable and consistent environment over an extended period.
- Extended Support: Offers a three-year support window with patches and updates.
- Reduced Risk: Minimizes disruptions from major changes and breaking updates.
STS (Standard-Term Support):
Standard-Term Support (STS) versions are released in the years between LTS versions and are identified by odd numbers (e.g., .NET 5, .NET 7). They have a shorter support cycle and offer 18 months of free support and updates.
STS versions are ideal for applications that benefit from the latest features and improvements. They allow developers to quickly access cutting-edge innovations and performance enhancements, and they are suited for projects that prioritize rapid development and deployment cycles.
Benefits of STS:
- Access to latest features: Provides the newest innovations and performance improvements.
- Frequent updates: Offers regular updates and quicker access to fixes and new capabilities.
- Agility: Supports rapid development and deployment, fostering innovation and adaptation to new market demands.
Comparison: Differences and use cases
The primary difference between LTS and STS versions lies in their support duration and release cycles. LTS versions are designed for long-term stability, offering extended support and minimizing the need for frequent upgrades. This makes LTS ideal for enterprise applications, long-term projects, and industries where stability and compliance are essential.
In contrast, STS versions are geared towards innovation and agility, providing access to the latest features and improvements. These versions are suited for short-lived applications, innovative projects, and non-production environments where rapid iteration is essential.
Upgrade instructions
Upgrading to a new .NET Core version involves multiple steps to ensure your development environment, source code, continuous integration (CI), and hosting environment are all appropriately updated. Below are detailed instructions to guide you through the process.
Common reasons to upgrade:
- The current .NET version is no longer supported.
- The new version supports a new operating system.
- The new version includes important API, performance, or security features.
Step 1: Upgrade the development environment
The first step in the upgrade process is to ensure your development environment is ready for the new .NET version. The .NET SDK, which includes the .NET CLI, build system, and runtime, needs to be updated.
- Download the installer: Visit the .NET download page and download the installer for your operating system.
- Run the installer: Follow the on-screen instructions to install the new .NET SDK.
- Use package manager (optional): Some operating systems allow installation via a package manager (e.g., Homebrew for macOS, apt-get for Linux).
- Visual Studio users: If you use Visual Studio, upgrade to the latest version of Visual Studio, which will automatically include the latest .NET SDK.
Verify installation:
Open a command-line interface and run the following commands to ensure the new SDK is installed:
dotnet –list-sdks
dotnet –list-runtimes
Step 2: Upgrade source code
Next, you must update your project files to target the new .NET version.
- Open the project file: Locate and open your project file (e.g., *.csproj, *.vbproj, or *.fsproj).
- Update TargetFramework: Change the <TargetFramework> property value to the new version. For example:
<TargetFramework>net6.0</TargetFramework>
to
<TargetFramework>net8.0</TargetFramework>
- Use upgrade assistant: The .NET Upgrade Assistant tool can automate these changes.
- Build the project: Rebuild your project using the new SDK. The command-line command for this is:
dotnet build
- Restore workloads: If needed, restore workloads with the new SDK version using:
dotnet workload restore
Step 3: Update continuous integration (CI)
Ensure your CI pipeline is updated to use the new .NET SDK. Update the configuration files for your CI system (e.g., GitHub Actions, Azure Pipelines) to reference the new .NET version.
- Modify configuration files: Update the .NET version in your CI configuration files to match the new version.
- Run CI pipelines: Execute your CI pipelines to verify that the build and test processes work correctly with the new .NET version.
Step 4: Update hosting environment
Lastly, update your hosting environment to support the new .NET version. This step ensures that your production environment can run the upgraded application.
- Install new .NET runtime: Ensure the hosting environment has the new .NET Runtime installed. This might involve updating server configurations or using container images with the latest runtime.
Deploy application: Deploy your upgraded application to the hosting environment and verify that it runs correctly.
Using the Command-Line Interface (CLI)
All installations of .NET Core SDK come with a command-line interface (CLI), allowing you to manually enter commands related to building, developing, and running your apps. If you’re unsure whether you have access to the dotnet CLI, follow these steps:
- Open a command window by pressing the Windows key + R, typing “cmd”, and pressing enter
- Type “dotnet” and press enter
- You should see the following text:
Usage: dotnet [options]
Usage: dotnet [path-to-application]
Options:
-h|–help Display help.
–info Display .NET information.
–list-sdks Display the installed SDKs.
–list-runtimes Display the installed runtimes.
path-to-application:
The path to an application .dll file to execute.
This indicates that you can use .NET Core commands in the CLI. All commands start with “dotnet” and are easy to remember.
To check the currently installed .NET Core SDK version, use this command:
dotnet –version
This will immediately show you the exact version of .NET Core you are currently running.
You can also use the command:
–list-sdks
To see which SDKs are installed and their locations on your machine.
Checking Multiple .NET Core Installations
Developers may have installed and utilized multiple versions of .NET Core and .NET. The previously mentioned command:
–list-sdks
shows exactly which versions of the .NET Core SDK are available. This should help developers understand why an SDK error may be occurring.
You can also use:
dotnet –list-runtimes
To show all installed runtime instances.
Note: You can find all currently installed SDK versions under the file path:
C:\Program Files\dotnet\sdk
This is unless you have manually chosen to install them elsewhere.
Understanding project-based version checks
Understanding the current .NET Core versions only really helps if you know the version used to create the project you’re trying to run. There are a couple of ways to assess this. If you’re using an integrated development environment (IDE) like Visual Studio, you can access the .NET Core SDK version from the project settings.
It’s also possible to use a .csproj file for C# projects. This file acts like the DNA of the app you’re developing, holding key information on how .NET Core should build the app. This includes data on which instance of .NET Core SDK was used to create the project. You can use an “msbuild /bl” command on your .csproj file, which creates an msbuild.binlog file. You can open this file with a Microsoft Build Log Viewer to view all properties and values related to the project, including the NETCoreSdkVersion, which tells you the exact version used to create the project.
You can also check the target framework within the .csproj file, which states the version of the SDK your project is trying to use to run itself. What do you do if that version isn’t installed? Simple: Head to the .NET downloads page and ensure you have the correct version to run the relevant project.
Version control is critical in development, allowing for smarter and more efficient troubleshooting and a smoother shift towards a DevOps mentality within your organization. Understanding how to check which .NET Core version is associated with each project helps eliminate SDK errors and empowers you to dramatically reduce your time to market.
Subscribe to our blog
Get articles like this delivered straight to your inbox