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

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

在以下情况，对服务器应用程序使用.NET Core：

1）用户有跨平台需求。

2）用户正在面向微服务。

3）用户正在使用Docker容器。

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

5）需按应用程序提供并行的.NET版本。

在以下情况，对服务器应用程序使用.NET Framework：

1）应用当前使用.NET Framework（建议扩展而不是迁移）。

2）应用使用不可用于.NET Core的第三方.NET库或NuGet包。

3）应用使用不可用于.NET Core的.NET技术。

4）应用使用不支持.NET Core的平台。

选择.NET Core 的情形

以下各部分对前面提到的选择.NET Core的原因进行了进一步说明。

跨平台需求

如果应用程序（Web/服务）需要在多个平台（Windows、Linux和macOS）上运行，请使用.NET Core。

.NET Core作为开发工作站支持前面提到的操作系统。Visual Studio提供了适用于Windows和macOS的集成开发环境(IDE)。还可使用运行于macOS、Linux和Windows上的Visual Studio Code。Visual Studio Code支持.NET Core，包括IntelliSense和调试。大多数第三方编辑器（如Sublime、Emacs和VI）都可搭配.NET Core使用。这些第三方编辑器可使用Omnisharp获取编辑器IntelliSense。也可不使用任何代码编辑器，直接使用适用于所有支持平台的.NET Core CLI 工具。

微服务体系结构

微服务体系结构允许跨服务边界组合使用技术。通过这种技术组合，可逐步接受.NET Core作为能与其他微服务或服务搭配使用的新微服务。例如，可组合使用微服务或使用.NET Framework、Java、Ruby或其他单片技术开发的服务。

可用的基础结构平台有很多。Azure Service Fabric，设计用于大型和复杂微服务系统。Azure App Service，很适合用于无状态微服务。基于Docker的微服务备选方案适合任何一种微服务方法，这部分内容将在容器部分进行说明。所有这些平台都支持.NET Core，是托管微服务的理想选择。

容器

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

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

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

如果系统需要最佳的性能和可伸缩性，.NET Core和ASP.NET Core是最佳的选择。Windows Server和Linux的高性能服务器运行时使.NET成为TechEmpower 基准上执行最佳的Web框架。

性能和可伸缩性对微服务体系结构尤为重要，体系结构中可能正在运行数百个微服务。借助ASP.NET Core，系统运行的服务器/虚拟机(VM)数要低得多。减少服务器/VM后可节省基础结构和托管成本。

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

若要安装含不同.NET版本上的依赖项的应用程序，建议使用NET Core。通过.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 Standard可跨各种.NET实现（包括.NET Core）共享代码。使用.NET Standard 2.0则更简单：

1）API曲面已变为更大。

2）引入了.NET Framework兼容性模式。此兼容性模式允许.NET Standard/.NET Core项目引用.NET Framework库。

因此，只有在库或NuGet包使用的技术在.NET Standard/.NET Core中不可用的情况下，才需要使用.NET Framework。

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

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

1）ASP.NET Web窗体应用程序：ASP.NET Web窗体仅在.NET Framework中可用。ASP.NET Core不能用于ASP.NET Web窗体。目前没有将ASP.NET Web窗体引入.NET Core的计划。

2）ASP.NET网页应用程序：ASP.NET网页未包含在ASP.NET Core中。ASP.NET CoreRazor 页与网页有许多相似之处。

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

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

5）语言支持：.NET Core目前支持Visual Basic和F#，但不是所有项目类型都支持。

除了正式的路线图，还有其他框架将植入.NET Core。若要查看完整列表，请参阅标记为port-to-core的CoreFX问题。此列表并不代表Microsoft承诺将这些组件引入.NET Core。这样做只是因为他们捕获到了社区所需。如果关注任何标记为port-to-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。

文章参考微软官网