NET Core 3.0 : SDK, Runtime and Set Up for Development

1. Introduction

.NET Core 3 was just released recently, along with C# 8, with powerful features and improvements. As I am planning to write a couple of articles about .NET Core and its interactions with different kinds of software packages, this is a good time to do so. This is likely to be the first of many articles about the .NET Core in my blog.

I will concentrate first on the topic of the .NET Core SDK and Runtime Versioning, and the Set up on a development machine in this article. .NET Core evolution has gradually resulted in many SDK and runtimes and installing the latest SDK and Runtime sometimes is not sufficient in my experience. Without a strong foundation and a good understanding of various things, a little hiccup is likely to throw us into confusion. This article is my attempt to demystify this kind of experience through many trials and errors and hopefully put us in a strong foot to start a .NET Core journey going forward. Potentially, there are many things I may have missed along the way, please feel free to comments and I am happy to rectify after some double-checking.

.NET Core is a cross-platform framework. You develop .NET Core applications on any platform; Windows, macOS or Linux, and deploy it to any other different platforms. For example, you can develop .NET Core applications on the Windows platform and deploy it to Windows, Linux or macOS. Or you can develop applications on the macOS platform and deploy it to Windows, Linux or macOS. You can do the same thing on the Linux platform as well. In this article, I will focus on the development on the Windows platform, even though sometimes issues around other platforms are mentioned in passing. The official website provides the Software Development Kit (SDK) and Runtime download for supported platforms.

The .NET Core SDK is a set of libraries and tools that allow developers to create .NET Core applications and libraries. It consists of these components:

• .NET Core Command Line Interface (CLI) tools
• .NET Core libraries, and runtime
• and the dotnet driver

You can develop applications using different IDEs (Integrated Development Environment) such as Visual Studio, Visual Code, or directly using the Command-Line Interface (CLI) tool that comes with the SDK. All of these IDEs use the same shared SDK framework, as explained in this MSDN article .

The .NET Core SDK uses MSBuild to build and publish .NET Core projects. The .NET Core SDK 3.0.100 currently uses MSBuild 16.3.0, and the file location is on the .NET Core SDK root folder (will be explained later). The CLI or dotnet build and publish commands are the wrapper of the MSBuild command. MSBuild allows projects to target multiple frameworks in the Microsoft universe; .NET Core, .NET Framework and some other frameworks, providing that the corresponding SDKs are available on the machine. For example, projects targeting .NET framework 4.5 requires that the .NET framework 4.5 SDK is installed. otherwise, it will not compile.

Each framework has the corresponding platforms the project can deploy to. .NET Core can be deployed to Linux, macOS, and Windows. The .NET Framework can be deployed on the Windows platform, and so on. In particular, when you are developing class library projects or Nuget packages, you want them to be used in various platforms if possible. Microsoft created a .NET Standard specification that serves as a common API across different Microsoft frameworks and it can be used as a project target like other frameworks. Figure 1 shows the matrix of frameworks supporting the .NET Standard API.

.NET Standard	1.0	1.1	1.2	1.3	1.4	1.5	1.6	2.0	2.1
.NET Core Runtime (s)	1.0	1.0	1.0	1.0	1.0	1.0	1.0	2.0	3.0
.NET Framework *	4.5	4.5	4.5.1	4.6	4.6.1	4.6.1 **	4.6.1 **	4.6.1 **	N/A ***
Mono	4.6	4.6	4.6	4.6	4.6	4.6	4.6	5.4	6.4
Xamarin.iOS	10.0	10.0	10.0	10.0	10.0	10.0	10.0	10.14	12.16
Xamarin.Mac	3.0	3.0	3.0	3.0	3.0	3.0	3.0	3.8	5.16
Xamarin.Android	7.0	7.0	7.0	7.0	7.0	7.0	7.0	8.0	10.0
Universal Windows Platform	10.0	10.0	10.0	10.0	10.0	10.0.16299	10.0.16299	10.0.16299	TBD
Unity	2018.1	2018.1	2018.1	2018.1	2018.1	2018.1	2018.1	2018.1	TBD

.NET Standard projects or packages can be used by projects targeting the framework version greater or the same as the version shown in Figure 1. The version number shown is the lowest version supported for a particular .NET Standard version. For example, a .NET Standard 1.4 class library can be used by a project targeting .NET Core 1.0 or greater and .NET Framework 4.6 or greater, and so on. So, when creating a .NET Standard project, aim for the lowest .NET Standard version possible.

The .NET Standard mapping to other frameworks is baked into the NuGet algorithm and used when deciding whether a project is compatible to use .NET Standard packages. There are few exceptions though. For example, while .NET Standard 1.5 to 2.0 are recognized by the Nuget as compatible for projects targeting 4.6.1, there is an issue in using such packages in the projects, and it is recommended to target .NET Framework 4.7.2 instead to avoid the problem altogether. Additionally, the .NET Framework stopped supporting from .NET Standard 2.1 and beyond. .NET Standard 2.0 is the highest you can target if they are going to be used in the .NET Framework projects. Apparently, .NET Core 3.0 and beyond is the future of .NET application, and the current .NET Framework 4.8 will be the last major version of the .NET framework (see this article).

A project identified the target frameworks using the Target Framework Moniker (TFM). The TFMs are specified in the TargetFrameworks (plural) or TargetFramework (singular) element.

<Project Sdk="Microsoft.Net.Sdk">
  <PropertyGroup>
     <TargetFrameworks> netstandard2.0; netcoreapp2.2; net472 </TargetFrameworks>
  </PropertyGroup>
</Project>

Figure 2 shows the TFMs that can be used to target .NET Core, .NET Framework and .NET Standard. For .NET Core, each of them corresponds to the [major.minor] version of .NET Core Runtime.

Target Framework	TFM
.NET Standard	netstandard1.0 netstandard1.1 netstandard1.2 netstandard1.3 netstandard1.4 netstandard1.5 netstandard1.6 netstandard2.0 netstandard2.1
.NET Framework	net11 net20 net35 net40 net403 net45 net451 net452 net46 net461 net462 net47 net471 net472 net48
.NET Core	netcoreapp1.0 netcoreapp1.1 netcoreapp2.0 netcoreapp2.1 netcoreapp2.2 netcoreapp3.0

2. NET Core Runtime: Versioning and Usage

In order to perform the set up correctly, it is important to understand how the .NET Core SDK and the .NET Core Runtime are versioned. The versioning of the .NET Core SDK is DIFFERENT from that of the .NET Core Runtime. Every .NET Core release contains both SDK and Runtime versions. The .NET Core release number matches the .NET Core Runtime version number.

The .NET Core Runtime version number has three parts 'Major.Minor.Patch' which follows the semantic versioning rules (read this MSDN article). MSBuild projects match a TFM with the major and minor parts of the .NET Core Runtime version number. In more detail, building a project will output the [project name].runtimeconfig.json file, which specifies the minimum runtime number the project can use to run. For example, the TFM netcoreapp1.0 corresponds to the .NET Core Runtime 1.0, and the file specifies the minimum runtime version is 1.0.5, which is a default value for .NET Core Runtime 1.0 (see below).

{
  "runtimeOptions": {
    "tfm": "netcoreapp1.0",
    "framework": {
      "name": "Microsoft.NETCore.App",
      "version": "1.0.5"
    }
  }
}

Once the file is created, it will not be overridden by another build. The tfm entry can be ignored as it is just a copy of what is in the project. The framework element is all that matters when you run the project, and it specifies the minimum runtime version to run. Alternatively, you can specify the RuntimeFrameworkVersion element in the project file and it will output the value instead. The value specified can be higher or lower than the default value.

<Project Sdk="Microsoft.Net.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp1.0</TargetFramework>
    <TargetFrameworkVersion>v1.0</TargetFrameworkVersion>
    <RuntimeFrameworkVersion>1.0.3</RuntimeFrameworkVersion>
  </PropertyGroup>
</Project>

In the project file, you can also specify TargetFrameworkVersion element. The element value must be the minor runtime version corresponding to the TFM. For example, for the TFM netcoreapp1.0, the corresponding runtime is 1.0. The value can be written with or without the case-sensitive prefix 'v'. You can omit TargetFrameworkVersion element in favor of the TFM, as they both must be aligned with each other. You can also omit the RuntimeFrameworkVersion and let the default policy take over. Generally, you only need to specify the TargetFramework or TargetFrameworks in the project file.

When you run the project, it fetches the runtimeconfig file and uses the highest patch of the minor version of the framework or runtime specified. If such runtime does not exist on the local machine, then it will look for the highest patch of the major version of the runtime, which process is called minor version roll-forward. It will not use any other major version number outside the major version of the runtime specified in the file. In fact, you can assign any runtime version regardless of the TFM specified in the project and will be treated as the minimum version to run the project. This process is well documented in this MSDN article. Figure 3 shows the TFMs and the associated .NET Core Runtimes, the default minimum version, the highest minor patches available, and the highest major patches available.

TFM	.NET Core Runtime	Minimum version/patch	Highest Minor patch available	Highest Major patch available
netcoreapp.3.0	3.0	3.0.0	3.0.0	3.0.0
netcoreapp2.2	2.2	2.2.0	2.2.7	2.2.7
netcoreapp2.1	2.1	2.1.0	2.1.13	2.2.7
netcoreapp2.0	2.0	2.0.0	2.0.9	2.2.7
netcoreapp1.1	1.1	1.1.2	1.1.13	1.1.13
netcoreapp1.0	1.0	1.0.5	1.0.16	1.1.13

The rules above are only applied when you try to run the project, e.g., using CLI command dotnet run from the project directory, or run the executable directly. When you build projects, e.g., using dotnet build, it uses the available SDK to compile, and outputs the [project name].runtimeconfig.json without trying to run it. So, if you don't have the correct runtime, you may still be able to compile or build the project using the SDK available.

3. NET Core SDK: Versioning and Usage

The .NET Core SDK version numbers, on the other hand, don't follow the semantic versioning rules. It also has three parts. The first and second parts are Major and Minor version numbers. The third part, expressed in 3 digits, is a combination of a Feature (first digit) and a Patch (second and third digits) numbers. By design, the SDK not only supports the Runtime version coming with its release, but also any other lower version numbers, which can be installed separately if it is required. For example, the .NET Core SDK 3.0.100 not only supports the Runtime 3.0 but also all the runtimes of 2.2, 2.1, 2.0, 1.1, and 1.0. However, the SDK 3.0.100 does not support the runtime greater than 3.0. A more detailed explanation of .NET Core versioning can be found in this MSDN article.

The CLI or dotnet command, by default, uses the latest .NET Core SDK available on the local machine. However, this behavior can be overridden by specifying the .NET Core SDK version in the global.json and placing it in the directory or any parent or grandparent directories where you run the command. The selection will start from the root directory and traverse up to the parent, etc. and the first global.json found will be used. If the specified version does not exist on the local machine, the latest patch of the specified SDK version is used. In particular, when .NET Core SDK 2.1 or higher is specified but not available, only the higher patch will be used, otherwise, an error is thrown. The global.json overriding rule does not work on Visual Studio (tried on Visual Studio 2017). The Visual Studio only uses the latest SDK feature supported. You can learn more about the supported SDK version for the Visual Studio in the last chapter.

Below is the example of global.json content.

{
  "sdk": {
    "version": "2.2.100"
  }
}

A complete explanation of the .NET Core SDK selection process and matching rules can be found in the MSDN article.

The .NET Core SDK also can be specified in the project file. If specified, it will be treated as the minimal version to compile the project. This can be useful if the project has a requirement that is only available from a particular SDK version. For example, if you are going to use the InProcess hosting model, which means hosting with IIS on Windows Platform, this is only available from .NET Core SDK 2.2 onward. If the version or higher SDK does not exist on the local machine, it will throw an error when compiling the project. For example, the project below specifies the minimal .NET Core SDK 2.2.100 in order to build for the TFM netcoreapp2.2 with an InProcess hosting model.

<Project Sdk="Microsoft.Net.Sdk/2.2.100">
  <PropertyGroup>
    <TargetFramework>netcoreapp2.2 </TargetFramework>
    <AspNetCoreHostingModel>InProcess</AspNetCoreHostingModel>
  </ProjectGroup>
</Project>

More about the .NET Core SDK selection process can be found in this MSDN article.

The .NET Core SDK is released more frequently than the Runtime. The table below shows the release of the SDK and the corresponding runtime.

Change	.NET Core Runtime	.NET Core SDK
Initial release	2.2.0	2.2.100
SDK Patch	2.2.0	2.2.101
Runtime and SDK Patch	2.2.1	2.2.102
Feature change	2.2.1	2.2.200
Preview release	Runtime 3.1.0-preview1.19506.1	SDK 3.1.100-preview1-014459

The initial release is when the minor runtime is up for one version, this normally also releases a new SDK version. Or the release can be just an SDK patch without any runtime changes. More often, the SDK and Runtime patch comes out together. Within one release, it can also have multiple SDK Feature versions. Normally, each feature version accommodates different versions of Visual studio or IDEs. Lastly, the preview release is used for testing. The preview SDK and runtime version is treated the same as their patch number, however, it is not higher than their stable version number. For example, the Runtime 3.1.0-preview1.19506.1 is higher than the Runtime 3.0.0 but lower than the Runtime 3.1.0.

4. Download and Release Page

It is time to get the download files. All installation and setup files can be download from this MSDN link , as shown in Figure 5.

This top-level download pages only show links to each minor version release. Following the link, each minor version has a number of SDK patches, features and preview releases, and multiple runtime version releases. The release version number is aligned with the Runtime versioning, not the SDK versioning. For example, the minor version release 2.2.7 corresponds to the Runtime 2.2.7. Each minor release version may have multiple SDK versions (sometimes they were even released at the exact same date). For example, the minor version release 2.2.7 corresponds to the feature SDK 2.2.109 (for Visual Studio 2017), SDK 2.2.206 (for Visual Studio 2019 16.0) and SDK 2.2.402 (General use, of the latest Visual Studio 2019). Figure 6 shows the .NET Core 2.2.7 release download page and Figure 7 shows its release note, which is linked in the first column.

The highest SDK feature is normally for general use and for the latest Visual Studio version available at the time of release. For example, SDK 2.2.402 can be used for Visual Studio 2019 16.2 as well as for the command line and Visual Studio Code. The other lower feature versions serve the previous versions of Visual Studio; version 2.2.206 is for Visual Studio 2019 16.0 and version 2.2.109 is for Visual Studio 2017. .NET Core generally will only work for Visual Studio 2017 and beyond, and the current stable version of SDK 3.0.100 and the Runtime 3.0.0 will only work with Visual Studio 2019 16.3. The support for Visual Studio for Mac OS has a different matrix as shown in Figure 8.

For other IDEs such as Visual Studio Code and other editors, though they can work with the lower feature versions of the same release, it is recommended to use the higher feature version. For example, for 2.2.7 release, it is recommended to use 2.2.402 version instead of any lower versions such as 2.2.109.

5. Installation

The next step is to download and install. Go to the current stable version .NET Core 3.0.0 download page as shown in Figure 9. I will mainly focus on the download for the Windows Platform.

If you develop applications, the SDK section in column two is all that you need. If you deploy applications in a production machine, go to the Runtime section in column three. The SDK already includes all the Runtime files for 'that' release. The exception to this is the Runtime & Hosting Bundle, which not only installs the Runtime but also configure IIS to work with ASP .NET Core applications for Windows deployments. Figure 10 shows IIS module entries after installing the Runtime & Hosting Bundle.

The Hosting bundle creates an IIS module entry called AspNetCoreModuleV2 which can run ASP.NET Core applications in InProcess mode, or integrated inside IIS pipeline. Earlier versions of the hosting bundle, up to ASP.NET Core 2.1, create an IIS module entry called AspNetCoreModule, which can only run ASP.NET Core applications in standalone or in OutProcess mode. This MSDN article explained the changes from the older version module to the newer version. The IIS module file location also differs depending on the IIS version and machine architecture, as explained in this MSDN article.

You only need one SDK on the development machine, and normally, this will be x64 or 64-bit architecture option unless your OS is x86 or 32-bit or ARM32. Normally, only the highest feature number of the latest SDK release is required unless you use a specific Visual Studio requiring a specific feature number of the SDK. All this information will be in the release notes. If you use Visual Studio and also the command line IDE, multiple SDKs may be required. Dotnet support side by side SDK versioning.

There are two routes to do the setup, either using an installer or binaries copy. The installer creates entries in the Apps & features and set Path variable in the platform Environment to point to the dotnet directory. The installer is only available on Windows and macOS platform.

Most installers only create one entry. The exception is the Runtime & Hosting Bundle installer that creates three installation entries; Microsoft.NET Core 3.0.0 - Windows Server Hosting, Microsoft.NET Core Runtime(x64), Microsoft.NET Core Runtime(x86). Any x64 installers will set the Path to '%PROGRAMFILES%\dotnet' , the default is 'C:\Program Files\dotnet'. Any x86 installers will set the Path to '%PROGRAMFILES(X86)%\dotnet', or 'C:\Program Files (x86)\dotnet'. So the Runtime & Hosting Bundle installer by default will add both entries to the Path variables.

This may be undesirable, as only the first path will be effective when you run dotnet command, so please make sure there is only one path in the Environment path. If you need to work with both 64-bit and 32-bit dotnet applications on the same machine, the best practice is to set the Path to point to x64 dotnet directory, so the 64-bit applications can use dotnet command from anywhere, and executes '%PROGRAMFILES%\dotnet\dotnet.exe" explicitly when running the 32-bit applications. Additionally, if you remove the installation via 'Apps & features', the installation directory will be removed only if no other installer still needs them.

The other route, the Binaries copy is a compressed archive that needs to be extracted manually to the correct directory. The Environment path to the dotnet directory needs to be set if it has not been done yet. The binary archive is zip for Windows, tar.gz for macOS and Linux. The directory structure is shown in Figure 11.

Under the dotnet directory (1), dotnet.exe (2) is the command-line tool, which can build, run, publish .NET Core projects. The SDK files are in the 'sdk' directory (3), and the Runtime files is in the 'shared' directory (4). .NET Core contains few runtimes and not just one, namely ASP.NET Core Runtime (5), .NET Core Runtime (6), and .NET Core Desktop Runtime (7). All these runtimes are actually meta-packages, which means they refer to other packages. Instead of referencing many packages in a project, you just need to reference one of these runtimes as if it is a single package.

The Microsoft.NetCore.App is a foundation runtime and all other runtimes have dependencies on it. The ASP.NET Core Runtime contains two runtimes; Microsoft.AspNetCore.App and Microsoft.AspNetCore.All. The Microsoft.AspNetCore.All includes Microsoft.AspNetCore.App and extra third-party packages. However, from .NET Core 3.0 and beyond, Microsoft.AspNetCore.All is not used anymore and any third-party package needs to be referenced separately in the ASP.NET Core project. Note, ASP.NET Core Runtime is only available from Core framework 2.1. The new Microsoft.WindowsDesktop.App runtime is only available for development and deployment in the Windows Platform, and it is available from Core framework 3.0 only.

On a production machine, you can install each runtime separately, depending on the type of .NET Core application you deployed. .NET Core Runtime is for console or command-line application. Use ASP.NET Core Runtime for deploying server applications. Alternatively, install Hosting & Runtime bundle for deploying .NET Core server application in IIS. This hosting bundle installs the AspNetCoreModuleV2 module in the IIS, the .NET Core Runtime and the ASP.NET Core Runtime. Note, the hosting bundle also installs both x64 and x86 type runtimes. You can fine-tune the hosting bundle to install only specific features in the command line parameter as explained in this MSDN link. Additionally, you can read the following MSDN article to learn how to create a .NET Core project to be hosted with IIS.

Below is my recommendation for the .NET Core setup on a development machine

For Command-Line, Visual Studio Code or Other IDE Users

If you use Visual Studio Code, Command-Line or any other IDEs, you just need the latest SDK, and the Runtime major patch of all earlier versions. Figure 12 describes the latest patch for each major version at the moment.

Major version	latest SDK major patch	latest Runtime major patch
3	3.0.100	3.0.0
2	2.2.402	2.2.7
1	1.1.14	1.1.13

So, you can either:

• Install the latest patch of the highest feature version of SDK (currently 3.0.100), and the latest patch of each earlier major version of the Runtime; 2.2.7 (major version 2) and 1.1.13 (major version 1). The current latest SDK already installs the Runtime 3.0.0. Each runtime version may have a different set of runtimes, and they all need to be installed separately. For example, the Runtime 3.0.0 have 3 runtimes; .NET Core, ASP.NET Core and .NET Core Desktop. The Runtime 2.2 and below have two runtimes; .NET Core and ASP.NET Core. The .NET Core Desktop is only deployable on the Windows platform. All other runtimes can be deployed on Windows, Linux or MacOs. The reason we install all the above runtimes is in order the dotnet run command to works on all .NET Core TFM or target frameworks on the development machine. For example, if your project targets the TFM netcoreapp2.0 and you execute dotnet run, it will minor version roll-forward to a higher minor version of the runtime available, which is 2.2.7 in above setup. The other command, dotnet build, only needs the latest SDK to be installed.
• Alternatively, install the latest path of each major SDK, 3.0.100 (major version 3), 2.2.402 (major version 2), 1.1.14 (major version 1). This is less hassle, as you don't need to install each .NET Core, ASP.NET Core, or other runtimes separately. The SDK includes them all in the installation. Using this approach, you use extra space for the additional SDK which is not going to be used. By default, only the latest SDK is used.

For Visual Studio Users

If you create .NET Core applications mainly from Visual Studio, be aware that some .NET Core versions of SDK may only be supported by a specific version of Visual Studio. Follow this MSDN link to see what .NET Core versions of SDK are supported by each of the Visual Studio versions. Generally, .NET Core is supported by Visual Studio 2017 onwards, and .NET Core 3.0 is only supported by Visual Studio 2019 onwards. There are SDK and Runtime download links for each minor version of .NET Core. The SDK number for the same minor version of the Runtime may be different for the Visual Studio 2017 and the Visual Studio 2019. For example, for release 2.2, the Visual Studio 2017 uses the .NET Core SDK 2.2.109, while the Visual Studio 2019 uses 2.2.402. The SDK 2.2.109 is the latest SDK supported by Visual Studio 2017. Additionally, the download links also assume that the Visual Studio has been upgraded to the latest patch version.

Following is my best practice recommendation if you use Visual Studio:

1. Install the Visual Studio, select ASP.NET and web development option, and select the .NET Core [x.x] development tools in the installation details. This installs the SDK, with the Runtime for each development tool selected.
2. Make sure the Visual Studio has the latest patch, particularly if you have installed Visual Studio a while ago. Go to menu Help -> Check for Updates
3. To check and update.
4. If you already have the Visual Studio installed, but not sure if it has .NET Core support, do step 2 to update with the 'latest patch' first and then modify the installation options by following step 1. To modify the Visual Studio installation, go to 'Add or remove programs' and click on Visual Studio [version].

Note, Visual Studio relies on the .NET Core installation to detect the version that is installed, so make sure you don't remove or add .NET core manually by deleting or adding the .NET Core related directory unless you absolutely know what you are doing. Sometimes, the latest upgrade of the Visual Studio may not be patched with the latest .NET Core SDK and Runtimes. To make sure, you can check the .NET Core directory or using dotnet -info and compared that with this Visual Studio .NET Core download link. If that is the case, you can install the latest SDK available for your Visual Studio using the download link provided.

Following the recommendation, you should be able to work with projects targeting any .NET Core versions supported by the Visual Studio version you used. Also, Visual Studio always uses the latest supported SDK available on the machine, and ignore project Sdk version configured in the project files or global.json. It gives a compilation warning informing it uses the latest version instead of the one configured.

Once you have installed the SDK and Runtime, you can check the latest SDK available on your machine by the following syntax:

C:\dotnet –-version
3.0.100

And the list of the SDKs you have installed on the machine:

C:\dotnet –-list-sdks
1.1.14 [C:\Program Files\dotnet\sdk]
2.1.202 [C:\Program Files\dotnet\sdk]
2.1.509 [C:\Program Files\dotnet\sdk]
2.2.109 [C:\Program Files\dotnet\sdk]
2.2.402 [C:\Program Files\dotnet\sdk]
3.0.100 [C:\Program Files\dotnet\sdk]

Lastly, to get all information about the .NET Core SDK and the .NET Core Runtime:

C:\dotnet –info
.NET Core SDK (reflecting any global.json):
 Version:   3.0.100
 Commit:    04339c3a26

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.17134
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\3.0.100\

Host (useful for support):
  Version: 3.0.0
  Commit:  7d57652f33

.NET Core SDKs installed:
  1.1.14 [C:\Program Files\dotnet\sdk] 
  2.1.202 [C:\Program Files\dotnet\sdk]
  2.1.509 [C:\Program Files\dotnet\sdk]
  2.2.109 [C:\Program Files\dotnet\sdk]
  2.2.402 [C:\Program Files\dotnet\sdk]
  3.0.100 [C:\Program Files\dotnet\sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.All 2.1.13 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.2.7 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.13 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.2.7 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.0.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 1.0.16 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 1.1.13 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.0.9 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.13 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.2.7 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.0.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 3.0.0 
            [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

To install additional .NET Core runtimes or SDKs:
  https://aka.ms/dotnet-download

The information includes:

• the latest SDK version
• the environment which is Windows platform and path of the SDK
• The host or the latest .NET runtime version
• The list of .NET Core SDKs
• The list of .NET Core runtimes

Now, we are ready to develop .NET core application on our development machine.

Please don't forget to vote if you find this article useful.

History

• 28^th October, 2019: Initial version