65.9K
CodeProject 正在变化。 阅读更多。
Home

NET Core 3.0：SDK、运行时和开发环境设置

kusnaditjung
starIconstarIconstarIconstarIcon
emptyStarIcon
starIcon

4.97/5 (12投票s)

2019年10月27日

CPOL

25分钟阅读

viewsIcon

27629

理解 .NET Core SDK、运行时和开发环境设置

1. 引言

.NET Core 3 和 C# 8 最近刚刚发布，它们带来了强大的功能和改进。由于我计划撰写几篇关于 .NET Core 及其与不同软件包交互的文章，现在正是时候。这可能是我博客中关于 .NET Core 的许多文章中的第一篇。

在本文中，我将首先集中讨论 .NET Core SDK 和运行时版本控制以及开发机器上的设置。根据我的经验，.NET Core 的演变逐渐产生了许多 SDK 和运行时，仅仅安装最新的 SDK 和运行时有时是不够的。如果没有扎实的基础和对各种事物的良好理解，一个小小的障碍都可能让我们感到困惑。本文是我通过多次尝试和错误来揭开这种经验的神秘面纱，并希望我们能够有一个坚实的基础，继续 .NET Core 的旅程。在此过程中，我可能遗漏了许多内容，请随时评论，我乐意在仔细核对后进行更正。

.NET Core 是一个跨平台框架。您可以在任何平台（Windows、macOS 或 Linux）上开发 .NET Core 应用程序，并将其部署到任何其他不同平台。例如，您可以在 Windows 平台上开发 .NET Core 应用程序，并将其部署到 Windows、Linux 或 macOS。或者您可以在 macOS 平台上开发应用程序，并将其部署到 Windows、Linux 或 macOS。您也可以在 Linux 平台上执行相同的操作。在本文中，我将重点介绍 Windows 平台上的开发，尽管有时会顺便提及其他平台的问题。官方网站提供了受支持平台的软件开发工具包 (SDK) 和运行时下载。

.NET Core SDK 是一组库和工具，允许开发人员创建 .NET Core 应用程序和库。它由以下组件组成：

  • .NET Core 命令行界面 (CLI) 工具
  • .NET Core 库和运行时
  • 以及 dotnet 驱动程序

您可以使用不同的 IDE（集成开发环境）来开发应用程序，例如 Visual Studio、Visual Code，或者直接使用 SDK 附带的命令行界面 (CLI) 工具。所有这些 IDE 都使用相同的共享 SDK 框架，如这篇 MSDN 文章 所述。

.NET Core SDK 使用 MSBuild 来构建和发布 .NET Core 项目。.NET Core SDK 3.0.100 当前使用 MSBuild 16.3.0，文件位置在 .NET Core SDK 根文件夹（稍后会解释）。CLI 或 dotnet build 和 publish 命令是 MSBuild 命令的包装器。MSBuild 允许项目在 Microsoft 生态系统中针对多个框架；.NET Core、.NET Framework 和一些其他框架，前提是机器上安装了相应的 SDK。例如，针对 .NET Framework 4.5 的项目需要安装 .NET Framework 4.5 SDK，否则将无法编译。

每个框架都有项目可以部署到的相应平台。.NET Core 可以部署到 Linux、macOS 和 Windows。.NET Framework 可以部署到 Windows 平台，等等。特别是，当您开发类库项目或 Nuget 包时，如果可能，您希望它们可以在各种平台上使用。Microsoft 创建了一个 .NET Standard 规范，作为跨不同 Microsoft 框架的通用 API，它可以像其他框架一样用作项目目标。图 1 显示了支持 .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 运行时 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 ** 不适用 ***
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
通用 Windows 平台 10.0 10.0 10.0 10.0 10.0 10.0.16299 10.0.16299 10.0.16299 待定
Unity 2018.1 2018.1 2018.1 2018.1 2018.1 2018.1 2018.1 2018.1 待定
图 1. 支持 .NET Standard API 的框架矩阵。（来源：MSDN 文章，解释了 *）

.NET Standard 项目或包可以被目标框架版本大于或等于图 1 所示版本的项目使用。显示的最低版本号是特定 .NET Standard 版本支持的最低版本。例如，.NET Standard 1.4 类库可以被目标为 .NET Core 1.0 或更高版本以及 .NET Framework 4.6 或更高版本的项目使用，以此类推。因此，在创建 .NET Standard 项目时，目标是尽可能低的 .NET Standard 版本。

.NET Standard 到其他框架的映射已内置到 NuGet 算法中，并在决定项目是否兼容使用 .NET Standard 包时使用。不过也有一些例外。例如，虽然 NuGet 认为 .NET Standard 1.5 到 2.0 与目标为 4.6.1 的项目兼容，但在项目中使用此类包存在问题，建议改为目标 .NET Framework 4.7.2 以完全避免该问题。此外，.NET Framework 停止支持 .NET Standard 2.1 及更高版本。如果您要在 .NET Framework 项目中使用它们，.NET Standard 2.0 是您可以目标的最高版本。显然，.NET Core 3.0 及更高版本是 .NET 应用程序的未来，而当前的 .NET Framework 4.8 将是 .NET Framework 的最后一个主要版本（请参阅本文）。

项目使用目标框架单点标识符 (TFM) 标识目标框架。TFM 在 TargetFrameworks （复数）或 TargetFramework（单数）元素中指定。

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

图 2 显示了可用于目标 .NET Core、.NET Framework 和 .NET Standard 的 TFM。对于 .NET Core，每个 TFM 都对应于 .NET Core 运行时的 [major.minor] 版本。

目标框架 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 Standard、.NET Core 和 .NET Framework 的 TFM。（来源：MSDN 文章）

2. .NET Core 运行时：版本控制和用法

为了正确执行设置，了解 .NET Core SDK 和 .NET Core 运行时如何进行版本控制非常重要。.NET Core SDK 的版本控制与 .NET Core 运行时的版本控制不同。每个 .NET Core 版本都包含 SDK 和运行时版本。.NET Core 版本号与 .NET Core 运行时版本号匹配。

.NET Core 运行时版本号有三部分“Major.Minor.Patch”，遵循语义版本控制规则（阅读这篇 MSDN 文章）。MSBuild 项目将 TFM 与 .NET Core 运行时版本号的主要和次要部分匹配。更详细地说，构建项目将输出 [project name].runtimeconfig.json 文件，该文件指定项目可以运行的最低运行时版本号。例如，TFM netcoreapp1.0 对应于 .NET Core 运行时 1.0，并且该文件指定最低运行时版本为 1.0.5，这是 .NET Core 运行时 1.0 的默认值（请参见下文）。

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

文件一旦创建，就不会被另一个构建覆盖。tfm 条目可以忽略，因为它只是项目中的一个副本。运行项目时，framework 元素才是最重要的，它指定了运行的最低运行时版本。或者，您可以在项目文件中指定 RuntimeFrameworkVersion 元素，它将输出该值。指定的值可以高于或低于默认值。

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

在项目文件中，您还可以指定 TargetFrameworkVersion 元素。元素值必须是与 TFM 对应的次要运行时版本。例如，对于 TFM netcoreapp1.0，对应的运行时是 1.0。该值可以带或不带区分大小写的“v”前缀写入。您可以省略 TargetFrameworkVersion 元素而使用 TFM，因为它们必须彼此对齐。您也可以省略 RuntimeFrameworkVersion 并让默认策略接管。通常，您只需要在项目文件中指定 TargetFramework 或 TargetFrameworks。

当您运行项目时，它会获取 runtimeconfig 文件并使用指定框架或运行时的次要版本的最高补丁。如果本地机器上不存在这样的运行时，它将查找运行时的主要版本的最高补丁，这个过程称为次要版本向前滚动。它不会使用文件中指定运行时的主要版本之外的任何其他主要版本号。实际上，您可以分配任何运行时版本，无论项目中指定的 TFM 如何，并且它都将被视为运行项目的最低版本。此过程已在此 MSDN 文章中详细记录。图 3 显示了 TFM 和相关的 .NET Core 运行时、默认最低版本、可用的最高次要补丁以及可用的最高主要补丁。

TFM .NET Core 运行时 最低版本/补丁 可用的最高次要补丁 可用的最高主要补丁
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
图 3. TFM 和相应的 .NET Core 运行时（最低版本/补丁由 .NET Core SDK 3.0.100 生成）

上述规则仅在您尝试运行项目时适用，例如，从项目目录使用 CLI 命令 dotnet run，或直接运行可执行文件。当您构建项目时，例如，使用 dotnet build，它会使用可用的 SDK 进行编译，并输出 [project name].runtimeconfig.json 而不尝试运行它。因此，如果您没有正确的运行时，您仍然可以使用可用的 SDK 编译或构建项目。

3. .NET Core SDK：版本控制和用法

另一方面，.NET Core SDK 版本号不遵循语义版本控制规则。它也有三部分。第一和第二部分是主要和次要版本号。第三部分以 3 位数字表示，是功能（第一位数字）和补丁（第二和第三位数字）数字的组合。根据设计，SDK 不仅支持其发布版本附带的运行时版本，还支持任何其他较低版本号，如果需要，可以单独安装。例如，.NET Core SDK 3.0.100 不仅支持运行时 3.0，还支持 2.2、2.1、2.0、1.1 和 1.0 的所有运行时。但是，SDK 3.0.100 不支持高于 3.0 的运行时。有关 .NET Core 版本控制的更详细解释，请参阅这篇 MSDN 文章。

CLI 或 dotnet 命令默认使用本地机器上可用的最新 .NET Core SDK。但是，可以通过在 global.json 中指定 .NET Core SDK 版本并将其放置在您运行命令的目录或任何父目录或祖父目录中来覆盖此行为。选择将从根目录开始，然后遍历到父目录等，找到的第一个 global.json 将被使用。如果指定的版本在本地机器上不存在，则使用指定 SDK 版本的最新补丁。特别是，当指定 .NET Core SDK 2.1 或更高版本但不可用时，将仅使用更高的补丁，否则将抛出错误。global.json 覆盖规则不适用于 Visual Studio（在 Visual Studio 2017 上尝试过）。Visual Studio 仅使用最新支持的 SDK 功能。您可以在最后一章了解有关 Visual Studio 支持的 SDK 版本的更多信息。

以下是 global.json 内容的示例。

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

有关 .NET Core SDK 选择过程和匹配规则的完整解释，请参阅 MSDN 文章。

.NET Core SDK 也可以在项目文件中指定。如果指定，它将被视为编译项目的最低版本。如果项目有仅在特定 SDK 版本中可用的要求，这会很有用。例如，如果您要使用 InProcess 托管模型，这意味着在 Windows 平台上使用 IIS 托管，这仅从 .NET Core SDK 2.2 及更高版本才可用。如果本地机器上不存在该版本或更高版本的 SDK，则在编译项目时会抛出错误。例如，下面的项目指定最低 .NET Core SDK 2.2.100，以便使用 InProcess 托管模型构建 TFM netcoreapp2.2。

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

有关 .NET Core SDK 选择过程的更多信息，请参阅这篇 MSDN 文章。

.NET Core SDK 的发布频率高于运行时。下表显示了 SDK 和相应运行时的发布情况。

更改 .NET Core 运行时 .NET Core SDK
首次发布 2.2.0 2.2.100
SDK 补丁 2.2.0 2.2.101
运行时和 SDK 补丁 2.2.1 2.2.102
功能变更 2.2.1 2.2.200
预览版 运行时 3.1.0-preview1.19506.1 SDK 3.1.100-preview1-014459
图 4. .NET Core 的不同发布类型。（来源：MSDN 文章 ）

最初的发布是当次要运行时版本上升时，这通常也会发布一个新的 SDK 版本。或者发布可能只是一个 SDK 补丁，没有任何运行时更改。更常见的是，SDK 和运行时补丁同时发布。在一个发布中，也可能有多个 SDK 功能版本。通常，每个功能版本都适应不同版本的 Visual Studio 或 IDE。最后，预览版用于测试。预览 SDK 和运行时版本与它们的补丁号相同，但它们不高于它们的稳定版本号。例如，运行时 3.1.0-preview1.19506.1 高于运行时 3.0.0 但低于运行时 3.1.0。

4. 下载和发布页面

是时候获取下载文件了。所有安装和设置文件都可以从 此 MSDN 链接 下载，如图 5 所示。

图 5. .NET Core 下载页面。（来源：https://dotnet.microsoft.com/download/dotnet-core）

此顶级下载页面仅显示每个次要版本发布的链接。点击链接，每个次要版本都有许多 SDK 补丁、功能和预览版本，以及多个运行时版本发布。发布版本号与运行时版本控制保持一致，而不是 SDK 版本控制。例如，次要版本发布 2.2.7 对应于运行时 2.2.7。每个次要发布版本可能包含多个 SDK 版本（有时它们甚至在同一日期发布）。例如，次要版本发布 2.2.7 对应于功能 SDK 2.2.109（适用于 Visual Studio 2017）、SDK 2.2.206（适用于 Visual Studio 2019 16.0）和 SDK 2.2.402（通用，适用于最新的 Visual Studio 2019）。图 6 显示了 .NET Core 2.2.7 发布下载页面，图 7 显示了其发布说明，该发布说明链接在第一列。

图 6. .NET Core 2.2.7 发布下载页面。（来源：https://dotnet.microsoft.com/download/dotnet-core/2.2）

图 7. .NET Core 2.2.7 发布说明。（来源：https://github.com/dotnet/core/blob/master/release-notes/2.2/2.2.7/2.2.7.md）

最高 SDK 功能通常用于通用和发布时可用的最新 Visual Studio 版本。例如，SDK 2.2.402 可用于 Visual Studio 2019 16.2 以及命令行和 Visual Studio Code。其他较低的功能版本服务于以前版本的 Visual Studio；版本 2.2.206 适用于 Visual Studio 2019 16.0，版本 2.2.109 适用于 Visual Studio 2017。.NET Core 通常只适用于 Visual Studio 2017 及更高版本，而当前稳定版本的 SDK 3.0.100 和运行时 3.0.0 只适用于 Visual Studio 2019 16.3。对 Visual Studio for Mac OS 的支持具有不同的矩阵，如图 8 所示。

图 8. 支持 .NET Core 的 Visual Studio for Mac 矩阵

对于其他 IDE，例如 Visual Studio Code 和其他编辑器，尽管它们可以使用同一发行版的较低功能版本，但建议使用较高功能版本。例如，对于 2.2.7 发行版，建议使用 2.2.402 版本而不是任何较低版本，例如 2.2.109。

5. 安装

下一步是下载并安装。前往当前稳定版本 .NET Core 3.0.0 下载页面，如图 9 所示。我主要关注 Windows 平台的下载。

图 9. .NET Core 3.0.0 下载页面。（来源：https://dotnet.microsoft.com/download/dotnet-core/3.0）

如果您开发应用程序，第二列中的 SDK 部分是您所需要的一切。如果您在生产机器上部署应用程序，请转到第三列中的运行时部分。SDK 已经包含了“该”版本的所有运行时文件。唯一的例外是运行时和托管捆绑包，它不仅安装运行时，还配置 IIS 以与 Windows 部署的 ASP.NET Core 应用程序一起使用。图 10 显示了安装运行时和托管捆绑包后的 IIS 模块条目。

图 10. 安装运行时和托管捆绑包后的 IIS 模块条目

托管捆绑包会创建一个名为 AspNetCoreModuleV2 的 IIS 模块条目，该模块可以在 InProcess 模式下运行 ASP.NET Core 应用程序，或者集成在 IIS 管道中。早期版本的托管捆绑包（直到 ASP.NET Core 2.1）会创建一个名为 AspNetCoreModule 的 IIS 模块条目，该模块只能在独立或 OutProcess 模式下运行 ASP.NET Core 应用程序。这篇 MSDN 文章解释了从旧版本模块到新版本的更改。IIS 模块文件的位置也因 IIS 版本和机器架构而异，如 这篇 MSDN 文章所述。

开发机器上只需要一个 SDK，通常是 x64 或 64 位架构选项，除非您的操作系统是 x86 或 32 位或 ARM32。通常，只需要最新 SDK 版本的最高功能号，除非您使用的特定 Visual Studio 需要特定功能号的 SDK。所有这些信息都将在发行说明中。如果您同时使用 Visual Studio 和命令行 IDE，可能需要多个 SDK。Dotnet 支持并行 SDK 版本控制。

设置有两种途径，一种是使用安装程序，另一种是二进制文件复制。安装程序在应用和功能中创建条目，并设置平台环境中的路径变量以指向 dotnet 目录。安装程序仅适用于 Windows 和 macOS 平台。

大多数安装程序只创建一个条目。例外是运行时和托管捆绑包安装程序，它创建三个安装条目；Microsoft.NET Core 3.0.0 - Windows Server Hosting、Microsoft.NET Core Runtime(x64)、Microsoft.NET Core Runtime(x86)。任何 x64 安装程序都会将 Path 设置为“%PROGRAMFILES%\dotnet”，默认为“C:\Program Files\dotnet”。任何 x86 安装程序都会将 Path 设置为“%PROGRAMFILES(X86)%\dotnet”，或“C:\Program Files (x86)\dotnet”。因此，运行时和托管捆绑包安装程序默认会将这两个条目添加到 Path 变量中。

这可能不是理想的，因为当您运行 dotnet 命令时，只有第一个路径会生效，因此请确保 Environment 路径中只有一个路径。如果您需要在同一台机器上同时使用 64 位和 32 位 dotnet 应用程序，最佳做法是将 Path 设置为指向 x64 dotnet 目录，这样 64 位应用程序可以在任何地方使用 dotnet 命令，并在运行 32 位应用程序时显式执行“%PROGRAMFILES%\dotnet\dotnet.exe”。此外，如果您通过“应用和功能”删除安装，则只有在没有其他安装程序仍然需要它们的情况下，安装目录才会被删除。

另一种途径是二进制文件复制，这是一个压缩存档，需要手动解压到正确的目录。如果尚未设置，则需要设置到 dotnet 目录的 Environment 路径。二进制存档在 Windows 上是 zip，在 macOS 和 Linux 上是 tar.gz。目录结构如图 11 所示。

图 11. Dotnet 目录结构。

在 dotnet 目录 (1) 下，dotnet.exe (2) 是命令行工具，可以构建、运行、发布 .NET Core 项目。SDK 文件位于“sdk”目录 (3) 中，运行时文件位于“shared”目录 (4) 中。.NET Core 包含几个运行时，而不仅仅是一个，即 ASP.NET Core 运行时 (5)、.NET Core 运行时 (6) 和 .NET Core 桌面运行时 (7)。所有这些运行时实际上都是元包，这意味着它们引用了其他包。您只需引用这些运行时之一，就像它是一个单独的包一样，而无需在项目中引用许多包。

Microsoft.NetCore.App 是一个基础运行时，所有其他运行时都依赖于它。ASP.NET Core 运行时包含两个运行时：Microsoft.AspNetCore.App 和 Microsoft.AspNetCore.All。Microsoft.AspNetCore.All 包含 Microsoft.AspNetCore.App 和额外的第三方包。但是，从 .NET Core 3.0 及更高版本开始，不再使用 Microsoft.AspNetCore.All，任何第三方包都需要在 ASP.NET Core 项目中单独引用。请注意，ASP.NET Core 运行时仅从 Core Framework 2.1 开始可用。新的 Microsoft.WindowsDesktop.App 运行时仅适用于 Windows 平台上的开发和部署，并且仅从 Core Framework 3.0 开始可用。

在生产机器上，您可以根据部署的 .NET Core 应用程序类型单独安装每个运行时。.NET Core 运行时用于控制台或命令行应用程序。使用 ASP.NET Core 运行时部署服务器应用程序。或者，安装托管和运行时捆绑包以在 IIS 中部署 .NET Core 服务器应用程序。此托管捆绑包在 IIS 中安装 AspNetCoreModuleV2 模块、.NET Core 运行时和 ASP.NET Core 运行时。请注意，托管捆绑包还安装 x64 和 x86 类型的运行时。您可以微调托管捆绑包，以仅在命令行参数中安装特定功能，如此 MSDN 链接中所述。此外，您可以阅读以下 MSDN 文章，了解如何创建 .NET Core 项目以托管在 IIS 中。

以下是我对开发机器上 .NET Core 设置的建议

对于命令行、Visual Studio Code 或其他 IDE 用户

如果您使用 Visual Studio Code、命令行或任何其他 IDE，您只需要最新的 SDK 和所有早期版本运行时的主要补丁。图 12 描述了当前每个主要版本的最新补丁。

主要版本 最新 SDK 主要补丁 最新运行时主要补丁
3 3.0.100 3.0.0
2 2.2.402 2.2.7
1 1.1.14 1.1.13
图 12. 命令行和 Visual Studio Code 的 .NET Core SDK 和运行时

所以，您可以选择

  • 安装最高功能版本的 SDK 的最新补丁（当前为 3.0.100），以及每个早期主要版本运行时的最新补丁；2.2.7（主要版本 2）和 1.1.13（主要版本 1）。当前最新的 SDK 已经安装了运行时 3.0.0。每个运行时版本可能有一组不同的运行时，并且它们都需要单独安装。例如，运行时 3.0.0 有 3 个运行时；.NET Core、ASP.NET Core 和 .NET Core 桌面。运行时 2.2 及以下有两个运行时；.NET Core 和 ASP.NET Core。.NET Core 桌面仅可在 Windows 平台上部署。所有其他运行时可在 Windows、Linux 或 macOS 上部署。我们安装所有上述运行时是为了让 dotnet run 命令在开发机器上适用于所有 .NET Core TFM 或目标框架。例如，如果您的项目目标是 TFM netcoreapp2.0 并且您执行 dotnet run，它将 次要版本向前滚动 到可用的更高次要版本的运行时，在上述设置中为 2.2.7。另一个命令 dotnet build 只需要安装最新的 SDK。
  • 或者，安装每个主要 SDK 的最新路径，3.0.100（主要版本 3）、2.2.402（主要版本 2）、1.1.14（主要版本 1）。这更省事，因为您无需单独安装每个 .NET Core、ASP.NET Core 或其他运行时。SDK 在安装中包含所有这些。使用这种方法，您会为不使用的额外 SDK 占用额外空间。默认情况下，只使用最新的 SDK。

对于 Visual Studio 用户

如果您主要使用 Visual Studio 创建 .NET Core 应用程序，请注意某些 .NET Core 版本的 SDK 可能仅受特定版本的 Visual Studio 支持。请遵循此 MSDN 链接 ，查看每个 Visual Studio 版本支持哪些 .NET Core 版本的 SDK。通常，Visual Studio 2017 及更高版本支持 .NET Core，Visual Studio 2019 及更高版本仅支持 .NET Core 3.0。每个 .NET Core 次要版本都有 SDK 和运行时下载链接。对于相同次要版本的运行时，Visual Studio 2017 和 Visual Studio 2019 的 SDK 版本号可能不同。例如，对于 2.2 版本，Visual Studio 2017 使用 .NET Core SDK 2.2.109，而 Visual Studio 2019 使用 2.2.402。SDK 2.2.109 是 Visual Studio 2017 支持的最新 SDK。此外，下载链接还假定 Visual Studio 已升级到最新补丁版本。

如果您使用 Visual Studio，以下是我的最佳实践建议

图 13. 支持 .NET Core 的 Visual Studio 安装示例
  1. 安装 Visual Studio，选择 ASP.NET 和 Web 开发选项，并在安装详情中选择 .NET Core [x.x] 开发工具。这将安装 SDK，以及为所选的每个开发工具提供的运行时。
  2. 确保 Visual Studio 已更新到最新补丁，特别是如果您很久以前安装了 Visual Studio。转到菜单 帮助 -> 检查更新
  3. 检查并更新。
  4. 如果您已经安装了 Visual Studio，但不确定它是否支持 .NET Core，请先执行步骤 2 更新到“最新补丁”，然后按照步骤 1 修改安装选项。要修改 Visual Studio 安装，请转到“添加或删除程序”并单击Visual Studio [版本]。

请注意，Visual Studio 依赖 .NET Core 安装来检测已安装的版本，因此请确保您不要手动删除或添加 .NET Core 相关目录，除非您完全了解自己在做什么。有时，Visual Studio 的最新升级可能未打上最新的 .NET Core SDK 和运行时补丁。为确保，您可以检查 .NET Core 目录或使用 dotnet -info 并将其与此 Visual Studio .NET Core 下载链接进行比较。如果出现这种情况，您可以使用提供的下载链接安装适用于您的 Visual Studio 的最新 SDK。

按照建议，您应该能够使用目标为您使用的 Visual Studio 版本支持的任何 .NET Core 版本的项目。此外，Visual Studio 始终使用机器上可用的最新受支持 SDK，并忽略项目文件中或 global.json 中配置的项目 Sdk 版本。它会发出编译警告，告知它使用最新版本而不是配置的版本。

安装 SDK 和运行时后，您可以使用以下语法检查机器上可用的最新 SDK

C:\dotnet –-version
3.0.100

以及您在机器上安装的 SDK 列表

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]

最后，获取有关 .NET Core SDK 和 .NET Core 运行时的所有信息

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

信息包括

  • 最新的 SDK 版本
  • 环境（Windows 平台和 SDK 路径）
  • 主机或最新 .NET 运行时版本
  • .NET Core SDK 列表
  • .NET Core 运行时列表

现在，我们已准备好在开发机器上开发 .NET Core 应用程序。

如果您觉得这篇文章有用，请不要忘记投票。

历史

  • 2019 年 10 月 28 日：初始版本
© . All rights reserved.