在.NET Core和.NET Framework之间选择服务器应用程序

使用.NET构建服务器端应用程序有两种支持的运行时选择：.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 / service），则最好的选择是使用.NET Core。

.NET Core还支持前面提到的操作系统作为开发工作站。Visual Studio为Windows提供集成开发环境（IDE）。您还可以在完全支持.NET Core的MacOS，Linux和Windows上使用Visual Studio代码，包括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 App Service。基于Docker的Microservices替代方案也适用于任何类型的微服务方法，如下所述。所有这些平台都支持.NET Core，使其成为托管您的微服务器的理想选择。

集装箱

容器通常与微服务架构一起使用，尽管它们也可以用于容纳根据任何架构模式的Web应用程序或服务。您将能够使用.NET Framework for 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，您可以使用较少数量的服务器/虚拟机来运行系统，从而最终节省基础架构和托管成本。

需要每个应用程序级别并行.NET版本

如果您希望能够在.NET中安装依赖于不同版本框架的应用程序，那么您需要使用.NET Core，它提供了100％并排的功能。在同一台机器上轻松并行安装不同版本的.NET Core，您可以在同一台服务器上拥有多个服务，每个服务器都有自己的.NET Core版本，可以消除风险并节省应用程序升级费用IT运营。

何时选择.NET Framework

虽然.NET Core为新应用程序和应用程序模式提供了显着的优势，但.NET Framework将继续成为许多现有方案的自然选择，因此，它不会被所有服务器应用程序的.NET Core所替代。

当前.NET Framework应用程序

在大多数情况下，您不需要将现有应用程序迁移到.NET Core。相反，推荐的方法是在扩展现有应用程序时使用.NET Core，例如在ASP.NET Core中编写新的Web服务。

需要使用不支持.NET Core的第三方.NET库或NuGet软件包

库正在迅速拥抱.NET Standard，它可以在所有.NET风格（包括.NET Core）中共享代码。使用.NET Standard 2.0，这将更容易，因为.NET Core API表面会变得更大，.NET Core应用程序可以直接使用现有的.NET Framework库。但是，这种转换不会立即发生，所以我们建议您在做出决定之前先检查应用程序所需的特定库。

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

.NET Core中没有一些.NET Framework技术。其中一些将在以后的.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网页不包括在ASP.NET Core 1.0中，尽管它计划在未来的版本中包含，如.NET Core路线图中所述。

• ASP.NET SignalR服务器/客户端实现。在.NET Core 1.0发布时间框架（2016年6月）中，ASP.NET SignalR不适用于ASP.NET Core（不是客户端或服务器端），尽管它计划被包含在将来的版本中，如.NET Core路线图。预览状态在服务器端和客户端库 GitHub存储库中可用。

• WCF服务实现。即使有一个WCF客户端库从.NET Core中使用WCF服务，截至2016年6月，WCF服务器实现仅在.NET Framework上可用。这种情况不是目前.NET Core的计划的一部分，但它将来会被考虑。

• 工作流相关服务：Windows Workflow Foundation（WF），工作流服务（单一服务中的WCF + WF）和WCF Data Services（以前称为“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问题。请注意，此列表不代表微软将这些组件带入.NET Core的承诺 - 它们只是捕捉到社区的愿望。话虽如此，如果您关心上述任何组件，请考虑参与GitHub的讨论，以便您可以听到您的声音。如果您认为缺少某些内容，请在CoreFX存储库中提出新问题。

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

某些Microsoft或第三方平台不支持.NET Core。例如，一些Azure服务，如服务结构状态可靠服务和服务结构可靠的演员需要.NET Framework。一些其他服务提供了一个尚未在.NET Core上使用的SDK。这是一个过渡的情况，因为所有的Azure服务都使用.NET Core。在此期间，您可以随时使用等效的REST API而不是客户端SDK。