ASP.NET Core

1. 安装 .NET Core

2. 创建一个新的 .NET Core 项目：

   mkdir aspnetcoreapp
   cd aspnetcoreapp
   dotnet new web
   

   注意:

   • 在 macOS 或者 Linux 系统上，打开一个终端窗口。 在 Windows 系统上， 打开命令行窗口。
   • 早期版本的 .NET Core 需要一个 t 参数，比如 dotnet new -t web。 如果你运行 dotnet new web 出错， 安装最新版本的 .NET Core. 输入 dotnet (不需要参数) 将会显示 .NET Core 版本。

3. 还原包：

   dotnet restore
   

4. 运行应用程序（ dotnet run 命令在应用程序过期（配置或代码发生变更）时重新生成它）：

   dotnet run
   

5. 浏览 http://localhost:5000

为服务器应用选择 .NET Core 或 .NET Framework

有两种支持的运行时可用于通过 NET Framework 和 .NET Core 生成服务器端应用程序。 这两者共享了大量相同的 .NET 平台组件，用户可在它们之间共享代码。 但两者之间存在根本的差异，可根据需要实现的目标进行选择。 本文介绍了在何种情况下进行选择。

在以下情况，应该为服务器应用程序选择使用 .NET Core：

• 用户有跨平台需求。
• 用户正在面向微服务。
• 用户正在使用 Docker 容器。
• 用户需要高性能和可扩展的系统。
• 用户根据应用程序需要并排 .NET 版本。

在以下情况，应该为服务器应用程序选择使用 .NET Framework ：

• 应用程序当前正在使用 .NET Framework（建议扩展而不是迁移）
• 用户需要使用不可用于 .NET Core 的第三方 .NET 库或 NuGet 包。
• 用户需要使用不可用于 .NET Core 的 .NET 技术。
• 用户需要使用不支持 .NET Core 的平台。

选择 .NET Core 的情形

以下是对前面提到的选择 .NET Core 的原因的更详细的说明。

跨平台需求

如果你的目标是拥有能跨平台（Windows、Linux 和 macOS）运行的应用程序（Web/服务），.NET Core 无疑是最佳选择。

.NET Core 作为开发工作站还支持前面提到的操作系统。 Visual Studio 提供用于 Windows 的集成开发环境 (IDE)。 你还可以在 macOS、Linux 和 Windows 上使用 Visual Studio Code，它们完全支持 .NET Core，包括 IntelliSense 和调试。 此外，你还可以使用大多数第三方编辑器（如 Sublime、Emacs 和 VI）面向 .NET Core，并使用开源 Omnisharp 项目获取编辑器 IntelliSense。 也可以不使用任何代码编辑器，直接使用适用于所有支持平台的 .NET Core 命令行工具。

微服务体系结构

如果你要选择使用面向微服务的系统（该系统由多个独立的、可动态伸缩的、有状态或无状态的微服务组成），.NET Core 将是最佳选择。 .NET Core 是轻型平台，其 API 图面可最小化到微服务范围。 微服务体系结构还允许混合跨服务边界的技术，从而逐渐接受新微服务的 .NET Core，这些新的微服务与使用 .NET Framework、Java、Ruby 或其他整体化技术开发的其他微服务或服务结合使用。

可供使用的基础结构平台有很多。 对于大型和复杂微服务系统，可以使用 Azure Service Fabric。 对于无状态的微服务，还可以使用其他产品（如 Azure 应用服务）。 基于 Docker 的微服务备选方案也适合于任何一种微服务方法，将在下一部分中进行说明。 所有这些平台都支持 .NET Core，是托管微服务的理想选择。

容器

虽然容器通常与微服务体系结构结合使用，但是也可用于容器化遵循任何体系结构模式的 Web 应用或服务。 虽然能够将 .NET Framework 用于 Windows 容器，但 .NET Core的模块化和轻型性质使之成为容器的最佳选择。 在创建和部署时容器时，使用 .NET Core 时容器的映像大小要远小于使用 .NET Framework 时的大小。 例如，因为它是跨平台的，所以可以将服务器应用部署到 Linux Docker 容器。

然后，可以在自己的 Linux 或 Windows 基础结构中托管 Docker 容器，或使用云服务（例如 Azure 容器服务），在云中管理、协调和缩放基于容器的应用程序。

需要高性能和可扩展的系统

如果系统需要最佳的性能和可伸缩性，.NET Core 和 ASP.NET Core 是最佳的选择。 ASP.NET Core 的性能比 ASP.NET 高出 10 倍，领先于微服务的其他行业技术（例如 Java servlets、Go 和 node.js）。

这一点对微服务体系结构尤为重要，你可以运行数百个微服务。 通过使用 ASP.NET Core，能够大大减少运行系统所用的服务器/VM，最终节省基础结构和托管的费用。

需要按应用程序级别选择并行的 .NET 版本

如果想要在 .NET 的不同版本的框架上安装具有依赖项的应用程序，需要使用提供百分百并行的 .NET Core。 由于在同一台计算机上可轻松地并行安装不同版本的 .NET Core，用户可在同一台计算机上拥有多个服务，每个服务都在自己版本的 .NET Core 上，从而消除了风险并节约了应用程序升级和 IT 运营方面的资金。

选择 .NET Framework 的情形

虽然 .NET Core 为新的应用程序和应用程序模式带来的好处很明显，但在很多现有情况下仍然会选择 .NET Framework，因此不会将所有服务器应用程序的 .NET Framework 将替换为 .NET Core。

现有的 .NET Framework 应用程序

在大多数情况下，不需要将现有应用程序迁移到 .NET Core。 相反，若要扩展现有的应用程序（例如，在 ASP.NET Core 中写入新的 Web 服务），建议使用 .NET Core。

需要使用不可用于 .NET Core 的第三方 .NET 库或 NuGet 包

库可以快速接受 .NET Standard，这样可跨各种 .NET 版本（包括 .NET Core）共享代码。 如使用 .NET Standard 2.0，上述操作将更简单，因为 .NET Core API 图面会明显变大，.NET Core 应用程序可直接使用现有的 .NET Framework 库。 但此转换不会即时性生效，因此，我们建议在选择其中的一种方法前，请检查应用程序所需的特定库。

需要使用不可用于 .NET Core 的 .NET 技术

某些 .NET Framework 技术在 .NET Core 中不可用。 虽然某些技术将在更高版本的 .NET Core 中可用，但其他技术不会应用于 .NET Core 面向的新应用程序模式，因此可能永远不可用。 以下列表显示无法在 .NET Core 1.0 中找到的最常见技术：

• ASP.NET Web 窗体应用程序：ASP.NET Web 窗体上仅在 .NET Framework 中可用，因此该情况下不能使用 ASP.NET Core /.NET Core 。 目前没有将 ASP.NET Web 窗体引入 .NET Core 的计划。

• ASP.NET 网页应用程序：ASP.NET Core 1.0 中不包含 ASP.NET 网页，但计划将在未来版本中包括此项，详情请查看 .NET Core 路线图。

• ASP.NET SignalR 服务器/客户端实现。 在 .NET Core 1.0 发布时间范围内（2016 年 6 月），ASP.NET Core 不提供 ASP.NET SignalR（包括客户端和服务器），但计划将在未来版本中包括此项，详情请查看 .NET Core 路线图。 服务器端和客户端库 GitHub 存储库上的预览状态可用。

• WCF 服务的实现。 虽然 WCF 客户端库可从 .NET Core 使用 WCF 服务，但从 2016 年 6 月起，WCF 服务器实现只能在 .NET Framework 上可用 。 这种情况虽然不属于 .NET Core 当前计划，但将来会考虑这点。

• 工作流相关的服务：Windows Workflow Foundation (WF)、工作流服务（WCF + 单个服务中的 WF）和 WCF 数据服务（以前称为“ADO.NET 数据服务”）仅在 .NET Framework 上可用，尚未计划将其引入 .NET Core。

• Windows Presentation Foundation (WPF) 和 Windows 窗体：WPF 和 Windows 窗体应用程序仅在 .NET Framework 上可用。 没有将其移植到 .NET Core 的计划。

• 语言支持：Visual Basic 和 F # 目前没有工具支持 .NET Core，但 Visual Studio 2017 和更高版本的 Visual Studio 将支持这两种语言。

除了正式的路线图，还有其他框架植入 .NET Core - 若要查看完整列表，请查看标记为端口到核心的 CoreFX 问题。 请注意，此列表不代表 Microsoft 承诺将这些组件引入 .NET Core — 而只是从社区搜集达成此项的意愿。 尽管如此，如果对以上所列的任何组件感兴趣，请参与 GitHub 上的讨论，发表你的看法。 如果认为丢失了某些内容，请在 CoreFX 存储库中提出新的问题。

需要使用不支持 .NET Core 的平台

某些 Microsoft 或第三方平台不支持 .NET Core。 例如，某些 Azure 服务（如 Service Fabric Stateful Reliable Services 和 Service Fabric Reliable Actors）需要 .NET Framework。 某些其他服务提供尚不可用于 .NET Core 的 SDK。 这只是过渡情况，因为所有 Azure 服务都将使用 .NET Core。 在此期间，可用始终使用等效的 REST API 取代客户端 SDK

从 .NET Framework 移植到 .NET Core

如果已在 .NET Framework 上运行了代码，则可能会对在 .NET Core 1.0 上运行代码感兴趣。 本文提供移植过程的概述以及在移植到 .NET Core 时可能非常有用的工具列表。

移植过程概述

建议按照以下步骤进行移植过程。 该步骤的每个部分将在以后的文章中详细介绍。

1. 标识并记录第三方依赖项。

   因此需要了解什么是第三方依赖项，如何依赖于它们，如何查看它们是否也在 .NET Core 上运行，以及如果没有在其上运行可以采取的步骤。

2. 将希望移植的所有项目重定向目标到目标 .NET Framework 4.6.2。

   这可确保在 .NET Core 不支持特殊 API 的情况下，可以为特定于 .NET Framework 的目标使用备用 API。

3. 使用 API Portability Analyzer 工具来分析程序集并基于结果制定移植计划。

   API Portability Analyzer 工具将分析已编译的程序集并生成报表，该报表将显示高级可移植性摘要和不可用于 .NET Core 上的正在使用的每个 API 的细目。 可以使用此报表和代码库的分析结果一起制定移植代码的计划。

4. 移植测试代码。

   由于移植到 .NET Core 对代码库来说是很大的更改，因此强烈建议移植测试代码，以便在移植代码时可以进行测试。 如今，MSTest、xUnit 和 NUnit 都支持 .NET Core 1.0。

5. 执行移植计划！

帮助工具

以下是非常有用的工具的简短列表：

• NuGet - Nuget 客户端或 NuGet Package Explorer，是 Microsoft 针对 .NET 实现的包管理器。
• Api Portability Analyzer - 命令行工具或 Visual Studio 扩展，可生成有关 .NET Framework 和 .NET Core 之间代码移植性的报表的工具链，并且带有程序集到程序集的问题细目。 有关详细信息，请参阅 Tooling to help you on the process（过程中使用的帮助工具）。
• Reverse Package Search - 一个有用的 Web 服务，能够实现搜索某一类型并找到包含该类型的包。

移植到 .NET Core - 分析第三方依赖项

移植过程的第一步是了解第三方依赖项。 需要找出尚未在 .NET Core 上运行的依赖项（如果有），并为这些没有在 .Net Core 上运行的依赖项制定应变计划。

先决条件

今天，本文假定使用 Windows 和 Visual Studio，并拥有在 .NET Framework 上运行的代码。

分析 NuGet 包

分析 NuGet 包的可移植性非常简单。 因为 NuGet 包本身是一组包含特定于平台的程序集的文件夹，因此仅需检查确认是否存在包含 .NET Core 程序集的文件夹即可。

检查 NuGet 包文件夹最简单的方法是使用 NuGet Package Explorer 工具。 以下是使用方法。

1. 下载并打开 NuGet Package Explorer。
2. 单击“从在线源打开包”。
3. 搜索包的名称。
4. 展开右侧的“lib”文件夹并查看文件夹名称。

还可以在该包页面的“依赖项”部分下的 nuget.org 上查看包所支持的内容。

无论哪种情况都需要在 nuget.org 上查找具有以下任何名称的文件夹或项：

复制

netstandard1.0
netstandard1.1
netstandard1.2
netstandard1.3
netstandard1.4
netstandard1.5
netstandard1.6
netcoreapp1.0
portable-net45-win8
portable-win8-wpa8
portable-net451-win81
portable-net45-win8-wpa8-wpa81

这些是映射到 .NET Standard 版本的目标框架名字对象 (TFM) 以及与 .NET Core 兼容的传统可移植类库 (PCL) 配置文件。 请注意，兼容的 netcoreapp1.0 适用于应用程序，而非库。 尽管使用基于 netcoreapp1.0 的库没有任何不妥，但该库可能不适用于不是由其他 netcoreapp1.0 应用程序所使用的任何内容。

.NET Core 预发行版本中使用的某些旧 TFM 也可能兼容：

复制

dnxcore50
dotnet5.0
dotnet5.1
dotnet5.2
dotnet5.3
dotnet5.4
dotnet5.5

尽管这些可能适用于代码，但不保证其兼容性。 使用预发行的 .NET Core 包生成内含这些 TFM 的包。 请注意此类包更新为基于 netstandard 的包的情况。

备注

若要使用以传统 PCL 或预发行的 .NET Core 目标为目标的包，必须使用 project.json 文件中的 imports 指令。

NuGet 包依赖项未在.NET Core 上运行时应执行的操作

如果所依赖的 NuGet 包无法在 .NET Core 上运行，可以执行以下几项操作。

1. 如果项目是开放源代码并托管在诸如 GitHub 中，则可以直接与开发人员交流。
2. 可以通过搜索包并单击该包页面左侧的“联系所有者”即可直接在 nuget.org 上与作者取得联系。
3. 可以查找在.NET Core 上运行的其他包，这些包与所使用的包进行的是相同的任务。
4. 可以尝试自己编写包所执行的代码。
5. 可以通过更改应用的功能来清除对包的依赖性，至少在该包有可用的兼容性版本之前都能这样做。

请记住，开放源代码项目维护者和 NuGet 包发布者通常是因对给定域感兴趣且拥有不同的正常工作而免费参与的志愿者。 如果确实要参与，可能首先需要写一份关于库的积极声明，然后才能咨询有关 .NET Core 支持团队的内容。

如果采取上述任何操作都无法解决问题，则可能需要移植到最近版本的 .NET Core。

.NET 团队需要了解下次使用.NET Core 时哪些是需要支持的最重要的库。 还可发送邮件到 dotnet@microsoft.com，告知我们希望使用的库。

分析不是 NuGet 包的依赖项

用户可能拥有不是 NuGet 包的依赖项，如文件系统中的 DLL。 因此确定依赖项是否可移植的唯一方法是运行 ApiPort 工具。

移植到 .NET Core - 库

本文介绍了将库代码移植到 .NET Core 以使其跨平台运行的信息。

先决条件

本文假定你：

• 正在使用 Visual Studio 2017 或更高版本。 Visual Studio 的早期版本不支持 .NET Core。
• 了解推荐的移植过程。
• 已解决与第三方依赖项有关的任何问题。

还应熟悉下列主题的内容：

.NET Standard
此主题介绍了适用于所有 .NET 实现代码的 .NET API 正式规范。

包、元包和框架
这篇文章介绍了 .NET Core 如何定义和使用包，以及包如何支持多个 .NET 实现代码。

使用跨平台工具开发库
此主题介绍了如何使用跨平台 CLI 工具编写 .NET 的库。

.NET Core 的 csproj 格式的新增内容
本文概述了作为从移动到 csproj 和 MSBuild 的一部分，添加到项目文件的更改。

移植到 .NET Core - 分析第三方依赖项
本主题介绍了第三方依赖项的可移植性及 NuGet 包依赖项无法在 .NET Core 上运行时要执行的操作。

.NET Framework 技术在 .NET Core 上不可用

一些适用于 .NET Framework 库的技术不可用于 .NET Core，例如 AppDomains、远程处理、代码访问安全性 (CAS) 和安全透明度。 如果库依赖于这些技术中的一个或多个，请考虑使用下面所述的替代方法。 有关 API 兼容性的详细信息，CoreFX 团队在 GitHub 上列出了行为更改/兼容性破坏和弃用的/旧 API 列表。

当前未实现某个 API 或技术并不因此意味着有意不对其提供支持。 在 GitHub 的 dotnet/corefx 存储库问题中提交问题，以请求特定 API 和技术。 问题中的移植请求已标有 port-to-core 标签。

AppDomain

AppDomain 可将应用相互隔离。 AppDomain 需要运行时支持并且通常价格昂贵。 .NET Core 中未实现它们。 我们不计划在将来添加此功能。 对于代码隔离，建议将流程分隔开来或将容器用作一种替代方法。 对于动态加载的程序集，我们建议使用新的 AssemblyLoadContext 类。

我们已在 .NET Core 中公开了一些 AppDomain API 图面，以便可以更轻松地从 .NET Framework 进行代码迁移。 一些 API 可正常工作（例如 AppDomain.UnhandledException），一些成员不会执行任何操作（例如 SetCachePath），也有一些会引发 PlatformNotSupportedException（例如CreateDomain）。 对照 dotnet/corefx GitHub 存储库中的 System.AppDomain 引用源检查所使用的类型，确保选择与已实现的版本相匹配的分支。

远程处理

.NET 远程处理被认为是存在问题的体系结构。 它用于进行跨 AppDomain 的通信，该通信现已不再受支持。 同样，远程处理也需要运行时支持，进行维护的成本较高。 出于这些原因，.NET Core 不支持 .NET 远程处理，并且我们不计划在将来添加对它的支持。

对于跨进程通信，可将进程间通信 (IPC) 机制视为远程处理的备用方案，如 System.IO.Pipes 或MemoryMappedFile 类。

对于跨计算机的通信，可将基于网络的解决方案用作备用方案。 最好使用低开销纯文本协议，例如 HTTP。 此处，ASP.NET Core 使用的 Web 服务器 Kestrel Web 服务器是一个选择。 也可考虑将System.Net.Sockets 用于基于网络的跨计算机的方案。 请参阅 .NET 开放源代码开发人员项目：消息传送了解更多选项。

代码访问安全性 (CAS)

沙盒依赖运行时或框架限制托管应用程序或库使用或运行的资源，其在 .NET Framework 上不受支持，因此在 .NET Core 上也不受支持。 我们认为 .NET Framework 中有许多发生特权提升以继续将 CAS 视为安全边界的情况和运行时。 此外，CAS 使实现更加复杂，通常会对无意使用它的应用程序造成正确性-性能影响。

可使用操作系统提供的安全边界，例如虚拟化、容器或用于运行进程的用户帐户具有最少的一组特权。

安全透明度

与 CAS 相似，借助安全透明度可以以声明性方式将沙盒代码与安全关键代码隔离，但是不再支持将它作为安全边界。 Silverlight 大规模使用了此功能。

可使用操作系统提供的安全边界，例如虚拟化、容器或用于运行进程的用户帐户具有最少的一组特权。

global.json

global.json 文件是可选文件，可以通过它设置项目的 .NET Core 工具版本。 如果正在使用 .NET Core 进行每日构建，并且想要指定 SDK 的特定版本，则可使用 global.json 文件指定该版本。 其通常位于当前的工作目录或其父目录之一。

JSON 复制

{
  "sdk": {
    "version": "2.1.0-preview1-006491"
  }
}

转换 PCL 项目

可以通过在 Visual Studio 2017 中加载库并执行以下操作来将 PCL 项目的目标转换为面向 .NET Standard：

1. 右键单击该项目文件，然后选择“属性”。
2. 在“库”下选择“目标 .NET 平台标准”。

如果包支持 NuGet 3.0，则此项目将重定向到 .NET Standard。

如果包不支持 NuGet 3.0，则将从 Visual Studio 收到一个对话框，告诉用户要卸载当前的包。 如果收到此通知，则执行以下步骤：

1. 右键单击项目，选择“管理 NuGet 包”。
2. 记录项目的包。
3. 将包逐一卸载。
4. 可能需要重启 Visual Studio 才能完成卸载过程。 如果需要重启，“NuGet 包管理器”窗口中将显示“重启”按钮。
5. 重载后，项目将面向 .NET Standard。 添加需要卸载的包。

将 .NET Framework 代码重定向到 .NET Framework 4.6.2

如果代码不面向 .NET Framework 4.6.2，建议重定向到 .NET Framework 4.6.2。 在 .NET Standard 不支持现有 API 情况下，这可确保最新备用 API 的可用性。

对于 Visual Studio 中每个想要移植的项目，请执行以下操作：

1. 右键单击该项目，然后选择“属性”。
2. 在“目标框架”下拉列表中，选择“.NET Framework 4.6.2”。
3. 重新编译项目。

因为项目现在面向 .NET Framework 4.6.2，因此可使用该版本的 .NET Framework 作为移植代码的基准。

确定代码的可移植性

下一步是运行 API 可移植性分析器 (ApiPort) 生成可供分析的可移植性报表。

确保了解 API 可移植性分析器 (ApiPort) 及如何生成用于面向 .NET Core 的可移植性报表。 执行此操作的方式可能取决于需求和个人偏好。 下面介绍了一些不同方法。 用户可能会发现自己根据生成代码的方式混合使用了这些方法中的步骤。

主要处理编译器

此方法可能最适合小项目或不会用很多 .NET Framework API 的项目。 此方法很简单：

1. 可选择在项目上运行 ApiPort。 若运行 ApiPort，则从报告获取有关需要解决的问题的信息。
2. 将所有代码复制到新的 .NET Core 项目。
3. 查看可移植性报表（如果已生成）时，解决编译器错误，直至项目完全得到编译。

尽管这种方法非常松散，但以代码为中心的方法通常可快速解决问题，并且可能是最适合小型项目或库的方法。 只包含数据模型的项目可能是此方法的理想选择。

可移植性问题得到解决前停留在 .NET Framework 上

如果更希望拥有在整个过程期间编译的代码，此方法可能是最佳选择。 该方法如下所示：

1. 在项目上运行 ApiPort。
2. 通过使用可移植的不同 API 解决问题。
3. 记录阻止你使用直接替代方案的所有区域。
4. 对所有要移植的项目重复前面的步骤，直到确信每个项目都做好被复制到新的 .NET Core 项目中的准备。
5. 将代码复制到新的 .NET Core 项目。
6. 解决所有已记录的不存在直接替代方案的问题。

这种谨慎的方法比单纯解决编译器错误更有条理，但相对而言，它仍以代码为中心，且优点是始终拥有编译的代码。 解决不能通过只使用另一个 API 解决的某些问题的方法大不相同。 你可能会发现对于某些项目，需要制定更全面的计划，这将在下一种方法中涉及到。

制定全面的施行计划

此方法可能最适合大型或更复杂的项目，在这种情况下，为支持 .NET Core，可能必需重构代码或将某些代码区域完全重写。 该方法如下所示：

1. 在项目上运行 ApiPort。
2. 了解每个非可移植类型使用的位置以及位置对整体可移植性的影响。
   • 了解这些类型的特性。 它们是否数量少，但使用频繁？ 它们是否数量大，但使用不频繁？ 它们是串联使用，还是在整个代码中传播？
   • 是否可以轻松隔离不可移植的代码，以便可以更有效地处理它？
   • 是否需要重构代码？
   • 对于这些不可移植的类型，是否存在可完成相同任务的备用 API？ 例如，如果使用WebClient 类，也许能够改用 HttpClient 类。
   • 是否存在其他可用于完成任务的可移植 API，即使它不是直接替代 API？ 例如，如果使用 XmlSchema 来分析 XML，但是无需 XML 架构发现，则可使用 System.Xml.LinqAPI 并自行实现分析，而不依赖于 API。
3. 如果具有难以移植的程序集，是否值得将其暂时留在 .NET Framework 上？ 以下是一些需要考虑的事项：
   • 库中可能具有某些与 .NET Core 不兼容的功能，因为它太依赖 .NET Framework 或 Windows 特定的功能。 是否值得暂时搁置该功能并发布在资源可用于移植这些功能前暂具较少功能的库的 .NET Core 版本？
   • 重构是否有用？
4. 编写自己对不可用 .NET Framework API 的实现是否合理？ 可以考虑复制、修改，并使用 .NET Framework 参考源中的代码。 参考源代码已在 MIT 许可证下获得许可，因此可以自由选择将此源作为自己代码的基础。 只需确保在代码中正确设置 Microsoft。
5. 根据不同项目的需要，重复此过程。

分析阶段可能需要一些时间，具体取决于代码库的大小。 在此阶段花费时间（尤其是在具有复杂的代码库时），全面了解所需的更改范围并制定计划，从长远看通常可节省时间。

计划可能包括对代码库做重大更改，同时面向 .NET Framework 4.6.2，使它成为前一种方法更有条理的版本。 着手执行计划的方式具体取决于代码库。

混合方法

在每个项目的基础上，可能会将上述方法进行混合。 应该进行对你和代码库最有意义的操作。

移植测试

要确保移植代码后一切正常的最佳方式是在将代码移植到 .NET Core 时进行测试。 为此，需要使用将针对 .NET Core 生成和运行测试的测试框架。 当前，有三个选择：

• xUnit
  • 入门
  • 将 MSTest 项目转换为 xUnit 的工具
• NUnit
  • 入门
  • 关于从 MSTest 迁移到 NUnit 的博客文章
• MSTest

移植的推荐方法

从根本上讲，移植工作在很大程度上取决于生成 .NET Framework 代码的方式。 移植代码的一个好方法是从库的基项开始，这是代码的基础组件。 这可能是数据模型或某些其他内容直接或间接使用的基本类和方法。

1. 移植测试项目，该项目测试当前正在移植的库层。
2. 将库中的基项复制到新的 .NET Core 项目，然后选择想要支持的 .NET Standard 版本。
3. 进行任何所需的更改，使代码进行编译。 大部分内容可能会要求将 NuGet 包依赖项添加到 csproj 文件。
4. 运行测试并进行任何所需调整。
5. 选择下一层代码进行移植，并重复前面的步骤。

如果从库的基项开始并从基项向外移动并根据需要测试每一层，移植将是一个系统化的过程，在这种情况下，问题可以一次隔离到一层代码中。