为什么将完整的 .NET Framework 与 ASP.NET Core 一起使用？答案

【问题标题】：Why use the full .NET Framework with ASP.NET Core?为什么将完整的 .NET Framework 与 ASP.NET Core 一起使用？
【发布时间】：2017-02-13 08:56:23
【问题描述】：

根据文档here，使用 ASP.NET Core 1.0 版本可以在 .NET Core 或完整 .NET Framework 上运行。我试图理解为什么要选择 ASP.NET Core + 完整的 .NET Framework 的后一个选项？

我了解完整的 .NET Framework 和 .NET Core 之间的区别。但是，如果我想使用完整的 .NET Framework，为什么不直接使用 ASP.NET 4.6？我认为这个想法是在 .NET Core 之上使用 ASP.NET Core 进行 1-2 的一击，允许跨平台部署、模块化、部署到 Docker 容器的能力、性能等一系列好处。没有 .NET Core 我不'不相信该列表中的任何内容仍然有效，那么完整的 .NET 框架 + ASP.NET Core 的用例是什么？如果没有 .NET Core，ASP.NET Core 本身仍能为我提供什么？

【问题讨论】：

参考这个 - stackoverflow.com/questions/37684508/…
这篇文章几乎完全回答了这个问题：odetocode.com/blogs/scott/archive/2016/10/11/…
微软网站上的解释：docs.microsoft.com/en-us/dotnet/articles/standard/…

标签： asp.net-core .net-core

【解决方案1】：

另一个原因是必须利用永远不会在 NET Core System.Data 中实现的 OLE DB 等遗留技术。

【讨论】：

【解决方案2】：

需要考虑的一点是，它可以是一条迁移路径。例如，假设您有一个现有的 ASP.NET 4.6 应用程序，您打算迁移到 .NET Core。您想利用 ASP.NET Core 功能，如 TagHelpers、依赖注入等，但您还没有准备好或无法使用 .NET Core 框架。因此，您开发 ASP.NET Core 应用程序，仅针对 .NET 完整框架。然后，您进行下一步和多目标，同时使用 .NET 完整框架和 .NET Core 框架。这使您可以灵活地轻松部署到具有完整框架的 IIS 或具有核心框架的跨平台。从那里，您可以决定是否要消除整个框架。

【讨论】：

这是真的吗？我认为针对完整 .NET Framework 的唯一区别是您可以引用一些尚未移植到 .NET Core 的 .NET Framework 程序集。关于部署和 IIS，它应该没有任何区别，如果你想要新版本的 ASP.NET，你仍然需要基本上改变与构建、部署和运行相关的所有内容，无论目标是什么。
@TomPažourek 这里的想法是您正在构建一个新的 .NET Core 应用程序，但您的库与 Core 不兼容。您可以开发 ASP.NET Core 应用程序并使用完整的 .NET Framework，但仍仅限于 Windows，因为这些程序集只能在 Windows 上运行。如果 .NET Core 没有来自完整框架的类似程序集，您需要找到一种解决方法（使用编译器指令和备用库）或禁用该功能以进行跨平台部署。目标仍然必须与应用程序的部署位置兼容。

【解决方案3】：

.NET Core 带来了许多好处，例如跨平台部署、模块化、部署到 Docker 容器的能力、性能等。如果没有 .NET Core，我不相信该列表中的任何内容仍然有效

如果您选择完整的 .NET 框架而不是 .NET Core，则唯一没有的好处是跨平台。部署、模块化、docker、性能等所有其他好处仍然有效。

我们实际上在完整框架上运行我们的 ASP.NET Core Web 应用程序，现在我们享受将依赖注入作为一等公民的好处，内置 NuGet，拥有精简的 HTTP 请求管道，这使我们的性能更好，开源（因此所有问题都可以通过短暂访问 GitHub 来解决）、模块化（在将近一年之后仍然必须遇到一些我们无法根据自己的需求定制的东西）等等。而且我们知道我们不需要在 Windows 以外的任何其他操作系统上进行部署，因此我们仍然可以享受完整框架的所有优势。

来自 Tseng 的更新

好吧，例如，您仍然可以在 Linux 下以完整的 .NET Framework 为目标。你需要在那里安装单声道 4.6。由于并非所有类都以单声道实现，因此存在一些限制，但大多数是在拐角处（即加密）您必须解决的问题

从 atconway 更新

如果需要的话，还值得注意的是 .NET Core 不支持 VB.NET。

【讨论】：

好吧，例如，您仍然可以在 Linux 下以完整的 .NET Framework 为目标。你需要在那里安装单声道 4.6。存在一些限制，因为并非所有类都以单声道实现，但大多数是在拐角处（即加密）你必须解决的问题
还值得注意的是，当时VB.NET 不支持.NET Core，如果这是一个要求的话。
用你的两个 cmets 更新
底层框架的选择也取决于你在做什么。据我了解，答案中的假设是，您正在制作应用程序而不是库。如果您正在开发一个库，那么答案会有所改变，因为您需要直接决定您需要以什么 TFM 为目标，即 .NET 标准。那时，您的库可以针对 .Net Core 或完整的 .Net 框架，具体取决于您的库需要什么 api。
@Danny van der Kraan：我无法编译多目标项目。创建一个新的 ASP.NET Core 2.0 Aurelia SPA 项目并更改为 net461;netcoreapp2.0 后，没有任何效果。我收到类似“名称空间‘Microsoft’中不存在类型或名称空间名称‘AspNetCore’......”之类的错误......！？？！

【解决方案4】：

将完整的 .NET 框架与 Asp.Net 核心一起使用的一个重要好处是可以使用成熟的库和框架，这些库和框架主要针对以前的 .NET 版本而开发。

但是随着时间的推移，实现越来越多的库以 .NET 核心为目标，并为 .NET 核心本身开发更多功能，这种优势可能会逐渐消失。

【讨论】：

【解决方案5】：

但是，如果我想使用完整的 .NET Framework，为什么不直接使用 ASP.NET 4.6？

如果我使用 ASP.NET 4.6 而不是 ASP.NET Core 1，那么我将无法使用 ASP.NET Core MVC。该文档页面上的所有功能都不会提供给我！我将不得不构建一个 MVC5 应用程序。嘘！

我试图理解为什么要选择 ASP.NET Core + 完整的 .NET Framework 的后一个选项？

我假设问这个问题的另一种方式是：“既然可以走棕色路，为什么还要走红色路？”

这样做的一个论据是部署。如果您有一堆现有的带有 IIS 的 Windows 服务器，您将需要在每个服务器上安装额外的软件并将它们设置为运行核心应用程序。 IIS 只是成为您的 .NET Core 应用程序的反向代理。

但是，如果这些应用程序是在 .Net Framework 上构建的，则您不必这样做。您仍然可以使用 web deploy（例如）将它们移动到服务器上。也许您有一些其他现有的 IIS 配置设置不想迁移。

使用面向 .Net Framework 的 ASP.NET Core 1.0，您可以从 ASP.NET Core MVC 中的新功能中受益，而无需更改现有基础架构。

【讨论】：

这是不正确的。如果您在 .NET Framework 上开发 ASP.NET Core Web 应用程序，则必须更新 IIS 配置。输出程序集是 .exe，而不是 .dll。唯一需要使用“红色路径”的情况是某些必需的 NuGet 包未移植到 .NET Core。