Aspnetcore: 从 Microsoft.AspNetCore.App 3.0 中删除程序集

我认为 MVC 包也应该成为额外的 NuGet 包。 MVC 很棒，但与普通的 ASP.NET Core 不同，它非常固执己见，我们的应用程序应该如何布局，这真的不是每个人都喜欢的，更不用说适合所有 .NET 语言的范式了。 我真的相信共享的 ASP.NET Core 框架应该是 MVC 免费的，或者有它的第二个 MVC 免费版本。 你怎么认为？

会有什么好处？ 这将如何使构建 ASP.NET Core 应用程序的人们的生活变得更好？

伟大的！ 当我使用asp.net core时，我只需要我需要的东西。

@davidfowl

会有什么好处？ 这将如何使构建 ASP.NET Core 应用程序的人们的生活变得更好？

出于同样的原因，您不包括在此问题顶部列出的软件包。 我只是认为将更多包添加到 .NET Core 3.0 附带的框架中总是比稍后删除包更容易。 为什么不开始添加最小的公分母来运行一个普通的 ASP.NET Core 应用程序，然后将其余的作为 NuGet 包提供。 如果事实证明这对开发人员来说是个问题，那么您以后可以随时添加更多内容，但以后将无法再轻松地删除内容。

因为我们也必须在默认情况下有用之间取得平衡。

好吧，我认为 vanilla ASP.NET Core 已经很有用（我认为你也这么认为，否则为什么不让它有用？）什么不是那么没关系;）

如果您是一个纯粹主义者，您将不会拥有大部分中间件或 MVC 或 SignalR，因为它们并不是绝对必要的。 在默认的事物集应该是什么和不应该是什么之间划清界限几乎是一种直觉和模糊的东西（根据经验，查看过去和现在的其他平台并拨打电话）。 从 ASP.NET Core 3.0 开始，我们没有计划将其移除（至少现在是这样）。

是的，我知道这总是一个艰难的决定，但有时我不确定（Microsoft）倾向于将事情膨胀到不必要的程度的理由是什么。 您如何在市场上定位自己的产品的方式就是如何看待它。 ASP.NET Core 应该是新的现代可组合且灵活的 Web 框架，但是您如何定位所有内容的方式是 ASP.NET Core 没有用，除非您强制每个人都使用 MVC + SignalR + Identity + EF。 在我看来，您已经确定了应该在何处绘制线条，这就是为什么 MVC 和 SignalR 没有嵌入在 ASP.NET Core 中，而是一个可以在需要时添加的单独框架，那么您现在为什么要模糊这些线条？ 感觉不一致，我想不出你能从中得到什么价值。 您不仅要推广 ASP.NET Core + 一个蓬勃发展的开源生态系统，还可以推广非常狭窄的 Web 体验。 它所做的只是让那些想要稍微与众不同并为自己做更多工作的人感到沮丧，因为您最终将事情推向了他们可能不想要的人。

如果你不把它塞进默认框架，人们就不会使用 MVC。 让它成为一个单独的 NuGet 包，没有人会抱怨他们必须从 NuGet 获取 MVC。 更有可能更多的人会来问为什么你用他们不想要的东西来膨胀默认框架，比如我。

我认为这是一个讨论，仍然是你们可能会考虑的事情，所以如果我想让你们问一件事，也许再次向你们的团队提出这个问题，看看你们是否真的准备好了，或者你可以对我的想法软化:)

PS：不确定是否是这种情况，但我希望 SignalR 也是一个单独的 NuGet 包。 这就像您将 Bootstrap 和 Angular2 包含到您的默认框架中一样。 如果这两个产品是由微软开发的，那么你可能会这样做，但它没有意义，我认为只是因为它们是由第三方完成的，你会发现它没有意义。

TBH 我很想看到更多的东西从默认安装中删除。 尤其是MVC。 这就是使 ASP.NET Core 之上的替代框架更具吸引力的原因。 我也想知道为什么像 ContentResult 这样的东西存在于 MVC 中而不是核心中。 它在 azure 函数中被大量使用，现在我总是不得不引用 MVC 的东西——只为 ContentResult。

我认为更重要的是，在 ASPNET SDK 中使用 MVC 内容不应该对您产生真正的负面影响。 大多数开发人员将使用它，因此以这种方式运送它比膨胀的恢复负载更受欢迎。 如果你不想要它，你可以不使用它。 上面列出的大多数包都引入了 3rd 方依赖项 (json)，有一些重要的方面 (razor)，或者在概念上与 ASPNET 分离并且经常在 SDK (EFCore) 之外引用。

尽管我同意默认最小值以促进 OSS 框架的平等竞争环境，但这确实必须平衡。 在核心（beta 甚至 1.0）的早期，到处都是包，这更令人困惑，恢复需要永远。

@psib​​ernetic即使东西在单独的包中，.net 核心安装程序也可以将这些包放在本地缓存中。

@psib​​ernetic你是第二个提到平衡很重要的人，但这到底意味着什么？ 什么之间的平衡？ 不谈极端，因为那显然不好，我们在这里谈谈现实的建议。 如果 MVC 是单个 NuGet 包，它会以何种方式影响可用性？ 它真的没有，这就是我的观点。 认为你将通过实施相反的极端来解决一个极端是狭隘的思维。 中间有很多。 框架不必臃肿，MVC 和 SignalR 也不必分成 100 个包。 两者都可以同时避免。

给我一个真实世界的案例，其中将 MVC 作为单个 NuGet 包会令人困惑，恢复需要永远，或者您提到的任何其他负面因素？

谈论恢复时间......

恕我直言，拥有快速启动的容器或无服务器架构（因为这对现实世界的业务有影响）比在开发人员机器上构建稍微快一点更重要。 是的，后者也非常重要，我希望它非常快，但是如果我必须对重要性进行排名，那么我宁愿在我的开发机器上受到轻微打击，而不是我在云中的生产基础设施。 因此，保持尽可能小的占用空间比缩短恢复时间更重要（如果不是更重要的话）。

会有什么好处？ 这将如何使构建 ASP.NET Core 应用程序的人们的生活变得更好？

我认为对于所有不使用 MVC 的其他用户来说，这是不需要的膨胀软件，比如我的 Windows 10 PC 上预装的 CandyCrush。 Asp.net 核心宣扬它对完全可配置的、根据需要的中间件等变得不那么固执己见。dotnet 模板允许 MVC 成为默认包含的包，而无需将其烘焙到核心中？

还有许多其他框架，如 Nancy、ServiceStack 和 Giraffe，它们都有自己的优点，不应该与不需要/不需要的 MVC 强制安装产生膨胀/冲突。 考虑到身份验证，剃刀，EF 等都打包了，但 MVC，当它不是核心时，金童子会成为核心框架的一部分，这似乎不一致？

如果是因为 MVC 与核心耦合如此紧密以至于解耦将是大量工作，我可以理解，但基于它通常使一些开发人员的生活更轻松，看起来很懒惰，非常像旧的 asp.net我希望我们远离 MVC 心态。

.NET Core 应该是用于 .NET 的 node.js 的精益模块化克隆，但它看起来并不打算复制促进其蓬勃发展、充满活力的生态系统的特征——一个小型、灵活的、不受限制的核心，包括功能由于没有与任何固执己见的 Web 框架捆绑在一起，因此在核心中受益，实验已经成熟，可以享受健康数量的流行框架和他们自己的独立社区。

我的意思是我让 ASP.NET 团队相信他们正在构建最好的框架，但并不是每个人都同意所选择的所有意见或完成某事所需的复杂程度。 .NET Core 中的所有内容都是在事后诸葛亮的情况下开发的，其中很多灵感来自于在其他平台上看到的成功方法，通过对使用哪些技术的意见进行烘焙，您正在挨饿来自 .NET 的下一个创新，甚至当下一件事确实在其他平台上受到关注时，ASP.NET Core 将处于复制其成功的劣势，因为我们将永远支付默认的“MVC 税”，希望每个人都将其开发模型用于所有 Web应用无穷无尽。

Node 的轻量级也使其适用于开发许多其他用例，如 Electron、原生移动应用程序、IOT、shell 脚本等。也就是说，这些用例都不能从在默认安装中捆绑 Web 框架中受益。 默认安装越臃肿，它在其他场景中的用处就越小。

IMO 的默认值应该回到 .NET Core 的原始愿景，即拥有一个精简的模块化核心，重点是让添加功能更容易（每个人都可以利用），即不是默认捆绑它并膨胀默认值安装。

感谢您的反馈。 让我分享一些想法。

1. 我们不修剪组件，因为我们只是喜欢它。 我们删除的每个程序集都是一个重大更改，并增加了从 2.x 升级到 3.0 的成本。 这些是我们用来决定 Microsoft.AspNetCore.App 的内容的指导原则： https :

2. 我们不会考虑从 Microsoft.AspNetCore.App 中删除 MVC。 虽然我们认识到并非每个用户都在他们的应用程序中引用 MVC，但我们相信这是 ASP.NET Core 产品的核心部分。 我们计划将其保留在 Microsoft.AspNetCore.App 中。

3. 自 2.1 以来，MVC 一直是 Microsoft.AspNetCore.App 的一部分，但正如您将在2.1“空 Web”模板 中看到的那样，您不必使用 MVC。 它在共享框架中的存在不会强制您在应用程序中使用它。 仍然欢迎您使用替代方案，编写您自己的视图框架，或者使用更“原始”的 aspnetcore API 来直接读取和写入 HTTP 请求和响应。

4. @dustinmoris ：我只是认为将更多包添加到 .NET Core 3.0 随附的框架中总是比稍后删除包更容易。 为什么不开始添加最小的公分母来运行一个普通的 ASP.NET Core 应用程序，然后将其余的作为 NuGet 包提供。 如果事实证明这对开发人员来说是个问题，那么您以后可以随时添加更多内容，但以后将无法再轻松地删除内容。

   这正是我们正在努力做的。 添加比删除更容易。 我们在 2.0 中添加了太多东西，并且我们正在重新调整回我们认为在可预见的道路上可维护的东西。 从 Microsoft.AspNetCore.App 中删除的大多数程序集仍将作为 NuGet 包提供。 如果我们后来发现 90% 的客户都引用了相同的包，那么这就是共享框架的一个很好的候选者。 然而，正如指导文档中提到的，API 的使用量是一个重要的指标，但不是我们考虑的唯一因素。

5. “香草”是主观的。 对于我们的许多用户来说，MVC 和 SignalR 是“普通的”。

6. 一些人说 .NET Core 应该是这个或那个或其他一些东西。 事情发生了变化，我们收集用户反馈，我们观察产品的使用方式，并尝试调整默认设置以匹配我们认为将使最大数量的客户受益的内容。 本期提出的调整反映了我们收到的关于 .NET Core 2.x 的反馈。

最后的想法：这个问题不会让每个人都高兴。 如果我们似乎无视您的反馈，我深表歉意。 请注意，我们有数十万客户，只有少数客户来到 GitHub 分享反馈。 我们还通过亲自访问、电话、电子邮件、社交媒体、客户支持请求、博客、Visual Studio 遥测等收集信息。 所有这些都是我们在做决定时考虑的部分，什么是默认体验的一部分，什么不是。

如果我们的动机或原因不清楚，请告诉我，我会尽力澄清。

如果您有这么多直接的客户联系，您最后一次询问他们中有多少人在使用 MVC 和 SignalR 是什么时候？ 这种立场背后是否有真正的使用指标，即绝对保留它们而不是将每个指标都放在一个可以在需要时很容易安装的单个 NuGet 包中？

@dustinmoris在共享运行时中包含 MVC 意味着它是预编译的，这是一个会丢失的好处，这将至少增加启动时间，使其，IMO，在您的快速启动示例中是一个糟糕的权衡码头集装箱。 除此之外，每个部署现在都需要随应用程序一起发送包，因为它不在运行时中，这增加了每个 MVC 应用程序的部署包大小。 最后，运行时中依赖于 MVC 的任何包也必须成为一个单独的可部署包，不确定有多少，因为我找不到完整列表。

说了这么多，请注意，我与 Microsoft 或 aspnet 团队的从属关系为 0，我可以看到发布的单独运行时是准系统的 aspnetcore 运行时，如果社区真的发声并证明这是一个主要需求。 我们的使命是为尽可能多的应用程序和开发人员提供出色的体验，而目前的事实是，共享运行时中从 MVC 中受益的人中有非常高的比例。 @natemcmaster是否有一种首选方式让相关个人在未来为此投票，也许是 GitHub 问题，这是一个合理的解决方案吗？

@psib​​ernetic欢迎您发起一个新的 GitHub 问题以从共享框架中删除 MVC，但正如我上面所说，从 Microsoft.AspNetCore.App 中删除 MVC 不是我们会考虑的事情，因此这个问题不太可能在我们的队伍。

@Bomret我们检查

@Natemcmaster ：我现在正在打电话，但感谢您的解释，我只是
当我在谈论的时候意识到这是关于元包的
共享框架。

@natemcmaster我认为@forki 、 @dustinmorris 、 @gerardtoconnor和@mythz已经陈述了非常合理的理由，我还没有听到反对的反对意见。 拥有一个基本的 Web 运行时/lib 会非常好，框架作者可以像 nodejs 一样构建在上面，而不是将固执的东西与其捆绑在一起。 正如之前提到的，node 之所以如此成功，是因为它没有太多要求，但提供了可以在其上构建的很好的抽象。 MVC 不会消失，它只会下台并成为各种其他 Web 库和框架中的一个选择。 通过包含它，你就为它表明了立场。 当然，大多数开发人员只是在运行时附带它，而不是进一步查看。 老实说，这听起来像是政治和营销——没有冒犯的意思。

它被称为“Microsoft.AspNetCore.App”，为什么不创建第二个“Microsoft.AspNetCoreMVC.App”？

无论如何，我知道这很难划清界限，但我认为这里的一般反馈是，越来越多的人喜欢你使用 aspnet core 所做的事情，但他们并不真正喜欢 MVC、razor 之类的东西、EF 或信号R。

的确。 您可以指望社区充满活力，可以为库和框架提供大量想法，以处理 api、web、websockets、模板、数据库访问等。 你们将为那些使用 MVC、Razor、EF 等的人提供一种选择，但不是唯一的，也不是默认的。

@natemcmaster我的错误，我实际上在这里讨论了这个问题中的共享框架。 我认为同样的原因也适用于元包，但老实说我不太关心这个，因为我已经可以引用单个包而不是元包，但是如果我想保留，我不能轻易地削减共享框架一个尽可能小的容器，所以你建议为共享框架开一个新问题是有道理的👍

@natemcmaster您能否快速确认我是否理解正确：

• 下一个 .NET Core 运行时 (3.0) 中将包含一个共享的 ASP.NET Core 框架，这意味着 ASP.NET Core 作为 .NET Core 安装的一部分在环境中提供。

• 此外，还有一个名为Microsoft.AspNetCore.App和Microsoft.AspNetCore.All包，它们是用于 ASP.NET Core 应用程序的 NuGet 包的集合

• 共享的 ASP.NET Core 框架 < 包含 EF Core 之类的东西的Microsoft.AspNetCore.App元包？

• 如果我只想创建一个非常小的 API，我可以构建一个 ASP.NET Core Web 应用程序而不必包含包含 EF Core、SignalR、MVC 等的Microsoft.AspNetCore.App元包？

• 无论你们在做什么，都可以创建一个 Docker 容器，它只对 ASP.NET Core 的依赖最少，以便运行一个微小的 API？

下一个 .NET Core 运行时 (3.0) 中将包含一个共享的 ASP.NET Core 框架，这意味着 ASP.NET Core 作为 .NET Core 安装的一部分在环境中提供。

是的

此外，还有一个名为 Microsoft.AspNetCore.App 和 Microsoft.AspNetCore.All 的元包，它们是 ASP.NET Core 应用程序的 NuGet 包的集合

不。有一个名为FrameworkReference的新概念，Microsoft.AspNetCore.App 就是其中之一。 Microsoft.AspNetCore.All 在 3.0 中将不存在。

共享的 ASP.NET Core 框架 < Microsoft.AspNetCore.App 元包，其中包括 EF Core 之类的东西？

不，它不包括 EF。

无论你们在做什么，都可以创建一个 Docker 容器，它只对 ASP.NET Core 的依赖最少，以便运行一个微小的 API？

使用程序集修整和链接器是的，不是通过删除包，因为 ASP.NET Core 不会有任何包。

@natemcmaster

我们不修剪组件，因为我们只是喜欢它。 我们删除的每个程序集都是一个重大更改，并增加了从 2.x 升级到 3.0 的成本。

进行任何更正的正确位置应在 v3 主要版本窗口内，这实际上是唯一可能发生此类更改的时间，即与其他软件包被删除的时间相同。

我们不会考虑从 Microsoft.AspNetCore.App 中删除 MVC。 虽然我们认识到并非每个用户都在他们的应用程序中引用 MVC。

它称为“Microsoft.AspNetCore.App”，如果您正在创建“ASP.NET Core 应用程序”，它在逻辑上读作“引用此包”。

我们相信这是 ASP.NET Core 产品的核心部分。 我们计划将其保留在 Microsoft.AspNetCore.App 中。

这越来越接近问题的症结所在，ASP.NET Core 的目标似乎正在远离培养精益、开放的 node.js 风格生态系统。 团队是否有意让每个人将 ASP.NET Core 应用程序混为一谈与 MVC 应用程序的同义词？ ASP.NET Core 的一些卖点是“付费玩”和解耦“分层”，但这表明“ASP.NET Core 应用程序”永远是 = MVC 应用程序。

如果包在以下位置更明确，那么参与的每个人都会更清楚：

• Microsoft.AspNetCore.App => 所有 ASP.NET Core 应用程序的基础
• Microsoft.AspNetCore.Mvc => ASP.NET Core MVC 应用程序

但是如果“Microsoft.AspNetCore.App”是不可触碰的，我们至少可以有一个官方的“基线”元包（或 FrameworkReference），只有核心服务器功能（即没有任何自以为是的库），一些潜在的命名：

• Microsoft.AspNetCore.[基础| 裸| 精简版 | 基本的]

（“核心”也很合适，但该术语已经被过度使用了）。

如果没有官方元包/名称，它就不会像当前推荐的“Microsoft.AspNetCore.App”那样易于访问，后者是所有 ASP.NET Core 应用程序的推荐基础。

约束孕育了创新，如果 MVC 只能在与其他人一样的竞争环境中运行，也许我们都可以访问一个功能，该功能允许我们轻松明确地声明应用程序需要哪些产品（又名套件套件），例如它可能看起来有些东西喜欢：

• Microsoft.AspNetCore.Mvc+SignalR+EF

每个人都可以轻松声明并只安装他们需要的东西，而幕后的工具可以结合“Microsoft.AspNetCore.Mvc”、“Microsoft.AspNetCore.SignalR”和“Microsoft.AspNetCore.EF”元包。 （或替代高级解决方案来实现意图）。

它在共享框架中的存在不会强制您在应用程序中使用它。

听起来像是有史以来创建的每个整体的基本原理。 “您不必使用我们捆绑的所有东西，它只是为了您的方便”。

仍然欢迎您使用替代方案，编写自己的视图框架，

它并不像您想象的那么受欢迎，例如，当我们开发自己的“视图框架”替代 MVC 和 Razor 时，我们在 .NET Core 中遇到了魔术行为，在运行标准命令以发布 . NET Core 项目，即：

 dotnet publish -c Release

哪个会失败：

EXEC(1,11): error CS0246: The type or namespace name 'System' could not be found (are you missing a using directive or an assembly reference?) [C:\src\NetC
oreWebApps\WebApp\src\WebApp\WebApp.csproj]
EXEC(1,54): error CS0518: Predefined type 'System.String' is not defined or imported [C:\src\NetCoreWebApps\WebApp\src\WebApp\WebApp.csproj]
C:\Program Files\dotnet\sdk\NuGetFallbackFolder\microsoft.aspnetcore.mvc.razor.viewcompilation\2.0.0\build\netstandard2.0\Microsoft.AspNetCore.Mvc.Razor.ViewCompilation.targets(60,5):

令人惊讶的行为，因为我们正在开发 MVC 的替代方案，该替代方案明确没有引用 MVC、Razor 或包含任何.cshtml页面，因为其目的是构建应用程序而不使用它们。

在搜索多个 GitHub 线程尝试不同的解决方法后，我发现其他人遇到了同样的问题，其中解决方案最终选择退出 MVC Razor 编译破坏构建：

dotnet publish -c Release /p:MvcRazorCompileOnPublish=false

这允许项目被发布。 在尝试不同的开关来修复损坏的构建的过程中，我们还发现我们可以通过选择退出不必要地膨胀我们的 .NET Core 2.0 Web 应用程序的元数据，将我们发布的足迹减少/refs/*.dll的150 个 .dll选择退出 Razor 所需的元数据：

<PreserveCompilationContext>false</PreserveCompilationContext>

所以基本上被迫玩打地鼠来找出我们需要告诉工具我们没有使用 MVC 的哪些开关来防止它破坏项目构建和输出不必要的元数据，只有 MVC/Razor 应用程序需要。 最好从“基本”元数据包开始，在这种情况下不可能出现此类问题，因为工具无法假设每个应用程序都在使用 MVC，因为 MVC 位不存在。

虽然很容易说 ASP.NET Core 仍然是一个受欢迎的平台，鼓励实验、创建和使用替代“视图框架”，但捆绑规定的自以为是的 Web 框架（如 MVC）几乎是最有害的事情，可以做来阻止创建和使用所述替代品的使用。 花点时间看看出现的流行替代品的数量是一个很好的衡量标准，以了解该平台对他们的吸引力。

如果每个 ASP.NET Core 应用程序都应该包含 MVC 而不是所有其他替代“视图框架”（包括 ext 方法的单个.cs文件插入）将显得更“重量级” "并且比使用捆绑的 MVC 麻烦，因为它们都需要与它捆绑在一起 + 视图框架需要的任何其他东西。

总而言之，如果选择加入“MVC”并且不包含在.App包中会更好，但是如果决定是不可逆转的，我们是否至少可以有一个官方的基线元包基础不包括吗？

请注意，我们有数十万客户，只有少数客户来到 GitHub 分享反馈。

IMO 对非臃肿启动包的需求没有得到充分体现，轶事：在我们为 VS 2012、VS 2013、VS 2015、VS 2017 和 .NET Core 创建的所有 C#/.NET 项目模板中，一直是最受欢迎的模板到目前为止一直是“空”模板，这也是对经典 ASP.NET 的频繁批评，即 VS.NET 默认的空 ASP.NET 模板不够空。 那时您可以在没有 MVC 的情况下创建“空的”经典 ASP.NET .NET 框架，但现在在更新、更轻且更模块化的 ASP.NET Core 框架中，MVC 捆绑在推荐的最低启动包中。

我们还从亲自访问、电话、电子邮件、社交媒体、客户支持请求、博客中收集信息

人们不喜欢膨胀，这通常等同于不可消除的复杂性，可能要求的是使项目尽可能简单，这应该是重点，并且可以在不膨胀默认项目的情况下完成。

根据我的经验，明确比具有神奇行为的臃肿框架更容易推理。 如果它是明确的，您可以与它交互，搜索它，阅读它，删除它，测试运行而不使用它（看看它是否是问题的原因），并且在比较不同配置的项目时它是可见的。 但是由于 MVC 工具的神奇行为破坏了上面我的 mvc/razor-less 项目的构建，我不知道我的项目的哪个部分触发了它，为什么它甚至在运行，如何禁用它或如何解决它。 我仍然不确定我不使用 MVC 的项目不会因为 MVC 被捆绑或它生成次优输出而变慢，因为它需要适应 MVC 或 Razor。

Visual Studio 遥测等。

很难比较一个不存在的基线元包的受欢迎程度的遥测，如果它做了 IMO，它将具有足够的受欢迎程度，值得将其包含在内。 以前的“Microsoft.AspNetCore.All”针对范围的另一端，包括宇宙，但不是具有最小有用基线的更有用的倒数。

如果您不构建 MVC 应用程序并且选择没有它的基线的选项同样易于访问，那么您为什么不选择它而不是包含 MVC 的更臃肿的启动选项？

@Bomret

拥有一个基本的 Web 运行时/lib 会非常好，框架作者可以像 nodejs 一样构建在上面，而不是将固执的东西与其捆绑在一起。

但这正是它的工作原理。 您可以按照自己想要的方式自由编写应用程序。 如果你不想使用MVC，就不要添加中间件。 是的，模板是可选的，但您可以使用任何您想要的方式更改您的应用程序以执行您想要的操作。

我认为您在这里有点误解了共享框架。 您只需将其视为一种随 .NET Core 一起提供的标准库。 做一个 Node 参考：想象一下当前版本的 Express 与 Node.js 捆绑在一起。 您不必_必须_使用它，但是当您想使用它时，它已经在那里了。

至于 MVC，我相信您并不完全了解 MVC 在 ASP.NET Core 中实际包含的内容。 如果您不想使用控制器和 Razor 视图，那很好，但无论如何您可能仍会在您的应用程序中使用相当多的 MVC 功能。

如果您不想使用控制器和 Razor 视图，那很好，但无论如何您可能仍会在您的应用程序中使用相当多的 MVC 功能。

像什么？

如果您不想使用控制器和 Razor 视图，那很好，但无论如何您可能仍会在您的应用程序中使用相当多的 MVC 功能。

是的，请告诉我，有点傲慢，我们中的大多数人都参与了基于核心中间件/kestrel 构建的替代框架，所以我们对我们正在使用的东西有一个很好的了解，控制器和 Razor 视图是 MVC 的一个小子集，我们我知道。 F# 框架 Giraffe/Saturn 和 Zebra 的性能优于 MVC，具有更好的路由和简化的处理模型。 在渲染方面，在 TechEmpower 上，Zebra x2 比 MVC 快，这就是为什么我们宁愿默认不使用它。 如果程序集修整/链接器能够在以后减少占用空间，那么这至少是一些东西，但如果默认情况下不包含它以允许其他框架更公平的竞争环境，那么这将是理想的，以获得对 asp.net 核心平台的最大吸引力。

@mythz从组织的角度来看，你是对的，这里有一些逻辑上的划分。 然而，任何细分都会显着增加复杂性和工程开销，这需要时间来改进产品的功能。 当我们期望绝大多数客户利用 MVC 组件时，将它们分开是不值得的。 不使用它们的开发人员的缺点可以忽略不计，安装目录中有一些额外的 MB，除非您加载它们，否则不会影响运行时。

我只能指出@mythz来说明这一点。 事物耦合得越多，它们就越纠缠在一起。 我是说瓦特！？ 即使您没有在任何地方引用它，MVC 也会影响 Asp 应用程序的构建？！

@戳
正如其他人已经写过的那样：事实并非如此。 它捆绑了与基本运行时无关的东西。 默认情况下，express 框架会与 node 捆绑在一起，您认为生态系统会变得如此充满活力和多样化吗？

我也绝对不明白如何从基本安装中删除 MVC、SingalR 等，并将它们作为单个 NuGet 包提供，每个包都可以标记为“增加的复杂性”。 无论如何，开发人员在大多数情况下都会安装额外的软件包。 如果将它们作为额外的包提供会“显着”增加恢复时间，那么它们无论如何都太胖了。

@Tratcher

然而任何细分

这所指的细分是 MVC 的解耦，因此 ASP.NET Core 应用程序可以有一个最小的有用基线，而没有任何自以为是的开发人员框架来规定他们应该使用什么来开发 ASP.NET Core 应用程序。

伴随着显着增加的复杂性和工程开销，需要时间来改进产品的功能。

澄清它是如何读取的：它需要太多的工程开销来从每个不使用 MVC 的 ASP.NET Core 应用程序中删除不必要的开销，因为如果 MVC 必须像所有其他替代框架一样工作，这将显着增加“MVC”的复杂性。

如果 MVC 需要显着的复杂性才能在所有其他替代框架必须在其中运行的相同可扩展性选项中工作，那么这表明 MVC 存在问题，并且添加的任何功能可以使其更无缝地工作，可以为每个人带来好处。 就像剖析一个整体一样，工具和运行时的复杂性将变得更精简和更简单，将增加的复杂性转移到它属于 MVC 及其集成/工具的位置。

相反，我们最终的情况是 MVC 根深蒂固在默认工具中，这可能会破坏发布项目并使不使用它的项目的输出膨胀。 由于它不像其他所有东西那样工作，因此无法告诉它您正在使用 MVC 或以任何方式告诉它您没有使用 MVC，因此总是假设它。

当我们期望绝大多数客户利用 MVC 组件时

嗯，这将是意料之中的事，这会损害其他所有替代方案，它是捆绑在默认最低推荐安装中的规定框架，例如 Apple 为每个人提供免费的 U2 歌曲，无论他们喜欢与否。

不使用它们的开发人员的缺点可以忽略不计

开发人员会从更健康的生态系统中受益吗？

开发人员是否受益于“ASP.NET Core 应用程序”是什么的额外混淆和模糊定义？ “它曾经像 .NET 的 node.js，但现在它更像是一个自以为是的单一供应商框架，其中基本上每个应用程序都以一堆自以为是的东西开始，这些内容规定了您应该如何构建 Web 应用程序，您可以将其视为每个默认情况下，应用程序预装了 express 及其依赖项 - 您应该使用它”

开发人员是否受益于 MVC 的特殊外壳？ 它不像其他任何东西一样安装或更新，它依赖于隐藏的工具和魔法行为，你必须四处寻找才能知道存在和禁用。 像这样的特殊大小写会增加意外的复杂性，在推理您的项目时，您必须维护一组不同的规则，用于 MVC 的工作方式与其他一切工作的方式。

如果它是明确的，它将提高可读性，您可以从项目配置中看出它是一个 MVC 应用程序，例如：

• 微软.AspNetCore.Mvc

这表明它是一个 MVC 应用程序并安装所有依赖项并自动配置所有定制工具 MVC 需求 - 理想情况下使用其他人都可以访问的相同开放可扩展模型。

通过将它保留在默认的“Microsoft.AspNetCore.App”项目中，您将永远将它与每个 ASP.NET Core 应用程序捆绑在一起，并使其不利于任何更好的出现。 ASP.NET Web Pages是多年前添加到 ASP.NET 的另一个 Razor 视图框架，该框架已安装并且默认启用了其侵入式魔术行为。 它带有自己的 Web Matrix IDE，该 IDE 不再受支持或可供下载，因此我们剩下的情况是，死技术的复杂性永远嵌入到经典的 ASP.NET 中，并积极地导致其他活动的 Web 框架出现问题捆绑使用 Razor .cshtml页面，这些页面永远需要携带以下包袱，以明确防止网页破坏其视图框架：

<appSettings>
    <add key="webPages:Enabled" value="false" />
</appSettings>

按优先顺序重新迭代功能请求将是：

1. 将“Microsoft.AspNetCore.App”更改为所有 ASP.NET Core 应用程序（即无 MVC）的最小有用基线。
2. 维护一个像“Microsoft.AspNetCore.Base”这样的元包，每个不使用 MVC 的人都可以将其用作最小有用的基线。

如果这些都不会被考虑，我们至少可以有一个像mvc:enabled = false这样的项目范围的标志，所有 MVC 工具都可以检查以禁用和阻止它们运行吗？

@mythz你把话放在我嘴里。 增加的复杂性不是 MVC，而是构建基础设施、打包、安装程序等，这些都是创建和交付另一层组件所必需的，而不管该层由什么组成。

如果这些都不会被考虑，我们是否至少可以有一个项目范围的标志，比如mvc:enabled = false ，所有 MVC 工具都可以检查以禁用和阻止它们运行？

您能否更具体地说明您希望禁用哪些工具功能？ 这可能值得一个单独的问题。

@Tratcher

增加的复杂性不是 MVC，而是构建基础设施、打包、安装程序等，这些都是创建和交付另一层组件所必需的，而不管该层由什么组成。

即为了让 MVC 工作所需的额外复杂性。

您能否更具体地说明您希望禁用哪些工具功能？ 这可能值得一个单独的问题。

我遇到的两个问题是需要手动配置/p:MvcRazorCompileOnPublish=false ，这会阻止我的项目（没有 .cshtml 页面）发布。 应该禁用的另一个标志是：

<PreserveCompilationContext>false</PreserveCompilationContext>

与大多数魔术行为一样，我假设还有更多，但只有在我遇到它们时才能找到它们。

基本上是一个标志，用于指定不使用 MVC 并禁用由于 MVC 而添加的所有默认启用的工具或让步。

@mythz继续并提交该问题。

如果您的用户关心额外的 MVC 和 SignalR dll，您实际上可以为服务堆栈创建一个类似的共享框架。

@davidfowl这实际上听起来非常棒，我可以看到社区提供的框架的一些不同用例。 有没有这方面的文件？

您可以想象，这不是我们会为之建立一流支持的事情，因为这样做的人数很少。 也就是说，您可以查看我们如何构建自己的行为并模仿这种行为。

@davidfowl最小基础包对于所有非 MVC 应用程序都很有用——例如，将有很多其他轻量级应用程序和微服务想要绕过所有框架并直接写入响应本身。 IMO 这个选项应该在框中可用，我们不希望从由我们无法控制的包版本组成的非官方基础开始。 理想情况下，所有内容都可以从基础包中添加，而不是从外部维护的不同切线开始。 但也许这是外部社区可以聚集在一起维护一个对所有非 MVC 应用程序和框架有用的基本“AspNetCore”子集的领域。

话虽如此，我们应该在哪里创建自定义框架？ 也许它会像从用于创建“Microsoft.AspNetCore.App”的内容的副本开始并剥离所有非必要的库以将其恢复为最小的有用子集一样简单。

@mythz为什么你甚至需要一个框架，你可以直接使用 Kestrel 服务器。 这只是说，也许你的光版本不是其他人对光或核心的想法。 我们目前有一个意见，如果社区能够站出来制作模板和一个足够小的替代共享框架，那将是令人惊讶的。 我们是 OSS，定制某些东西所需的一切都在那里，我们非常敏感，很乐意提供帮助。

@natemcmaster可以帮助提供有关如何制作自定义共享框架的详细信息。

@davidfowl你建议定制一个，我只是在能够从一个最小的有用基础开始而没有固执的框架之后。 我们不想单独引用多个包，原因与建议所有 ASP.NET Core 应用程序都引用“Microsoft.AspNetCore.App”的原因相同 - 能够引用单个包更容易访问。

这只是说，也许你的光版本不是其他人对光或核心的想法。

在这里，每个人似乎都非常一致地认为 MVC 不属于基础包。 似乎包含的唯一其他“产品”是 SignalR，我认为它的使用率比 MVC 少，而且包含的理由也更少。 我对每个包中的内容并不十分熟悉，但其他所有内容似乎都很有用，并且是 ASP.NET Core“平台”的有益部分。

好的，让我提出一个建议，尝试在这里具有建设性。 我们不会改变 Microsoft.AspNetCore.App，我们认为这是大多数用户需要和使用的东西。 让我们介绍另一个层，即这个“核心”共享框架（我们最初使用 https://www.nuget.org/packages/Microsoft.AspNetCore/2.2.0-preview3-35497 做了类似的事情）。 这是您将这些其他框架（如 Nancy 和 ServiceStack）建立在其之上的共享框架。

我们仍然会像现在一样使用 Microsoft.AspNetCore.App 提供我们的默认模板，但是像您这样的框架作者可以拥有其他使用基本共享框架的模板。

PS：这个线程并不代表我们的大多数客户，所以我不会单独从这里得出结论。 我们从很多地方得到反馈，github 有我们最直言不讳和热情的指导。

是的，我认为这更接近于包含配置应用程序并启动和运行的许多基本要素。 从Microsoft.AspNetCore.App 中的 deps 我们也使用：

• Microsoft.Extensions.Primitives
• 微软.AspNetCore.Http
• Microsoft.AspNetCore.Http.Abstractions
• Microsoft.AspNetCore.Http.Extensions
• Microsoft.AspNetCore.Hosting.Abstractions
• Microsoft.AspNetCore.Logging.Abstractions
• Microsoft.Extensions.DependencyInjection.Abstractions
• Microsoft.Extensions.Configuration.Binder
• Microsoft.AspNetCore.Cryptography.KeyDerivation

因此，像 HTTP、托管、日志记录和配置抽象（对大多数 HTTP 应用程序有用）之类的东西也很适合包含在内，以及任何其他人认为合适的东西。 我唯一的偏好是不包含 MVC/SignalR。

现在它变得有趣了。 正如大卫已经说过的：人们有不同的
“核心”是什么意思的想法。 从我的 POV 我不认为 DependencyInjection
应该在。/耸肩

Am Do., 8. Nov. 2018 um 08:30 Uhr schrieb Demis Bellot <
通知@github.com>：

是的，我认为这更接近于包含许多必需品
配置应用程序并使其启动并运行。 从深处
微软.AspNetCore.App
https://www.nuget.org/packages/Microsoft.AspNetCore.App我们也是
使用：

• Microsoft.Extensions.Primitives
• 微软.AspNetCore.Http
• Microsoft.AspNetCore.Http.Abstractions
• Microsoft.AspNetCore.Http.Extensions
• Microsoft.AspNetCore.Hosting.Abstractions
• Microsoft.AspNetCore.Logging.Abstractions
• Microsoft.Extensions.DependencyInjection.Abstractions
• Microsoft.Extensions.Configuration.Binder
• Microsoft.AspNetCore.Cryptography.KeyDerivation

诸如 HTTP、托管、日志记录和配置抽象之类的东西
（对大多数 HTTP 应用程序有用）也很高兴被包含在内
其他任何人认为合适的。 我唯一的偏好是没有
包括 MVC/SignalR。

—
你收到这个是因为你被提到了。
直接回复本邮件，在GitHub上查看
https://github.com/aspnet/AspNetCore/issues/3755#issuecomment-436898980 ，
或静音线程
https://github.com/notifications/unsubscribe-auth/AADgNOzUVEHlJNBrPD5P2BsQj6UQdqyvks5us92zgaJpZM4YAsZ1
.

@mythz其中大部分都是可传递的。

@forki 😆 欢迎来到我们的世界。

我们不会改变 Microsoft.AspNetCore.App，我们认为这是大多数用户需要和使用的东西。

著名遗言。 这是每一个错误决定的理由——“我们认为他们需要它”。

你知道我的想法吗？ 微软应该开始将其开发者群体视为独立的智能工程师而不是绵羊开发人员，是的，你们有很多绵羊开发人员，他们会跟随并使用你扔给他们的任何东西，但其他更有发言权的开发人员将成为一个充满活力的人社区并在 .NET 堆栈上建立新的初创公司。

有时听取高级用户的意见是件好事。

无论如何，我们不会改变 Microsoft.AspNetCore.App。 我提出了一个我认为满足这里要求的折衷方案。

@forki如果您使用的是 aspnet 核心，无论如何您都会遇到 DI，最好让它在默认情况下包含便利方法（获取服务, 获取必需服务和喜欢在那个包中）。 嘿，由于缺少 T，F# 甚至无法自己创建这些：> U 约束https://github.com/fsharp/fslang-suggestions/issues/255所以 ¯_(ツ)_/¯

我想提到那个基础共享框架@davidfowl ……我认为@mythz和@dustinmorris都可以采用这种方法。 这也是土星@Krzysztof-Cieslak 的好时机

无论如何你都面临着 DI

我知道，我们进行了多次讨论。 只是我宁愿不
;-） 但是它就是这样啊...

Am Fr., 9. Nov. 2018, 10:57 hat Nino Floris [email protected]
格施里本：

@forki https://github.com/forki如果你使用的是aspnet core
无论如何都要面对 DI，最好让它包含方便的方法
默认（获取服务，GetRequiredService 之类的就在里面
包裹）。 嘿，由于丢失了，F# 甚至无法自己创建这些
T :> U 约束 fsharp/fslang-suggestions#255
https://github.com/fsharp/fslang-suggestions/issues/255所以¯_(ツ)_/¯

我想要那个基础共享框架@davidfowl
https://github.com/davidfowl提到...我认为@mythz
https://github.com/mythz和 @dustinmorris
https://github.com/dustinmorris都可以采用这种方法。
这也是土星@Krzysztof-Cieslak 的好时机
https://github.com/Krzysztof-Cieslak

—
你收到这个是因为你被提到了。
直接回复本邮件，在GitHub上查看
https://github.com/aspnet/AspNetCore/issues/3755#issuecomment-437309244 ，
或静音线程
https://github.com/notifications/unsubscribe-auth/AADgNGP3d8R0otOauUQC7AYK6O2dzJ3mks5utVGegaJpZM4YAsZ1
.

更新了原始帖子以包括：

• Microsoft.AspNetCore.Authentication.JwtBearer
• Microsoft.AspNetCore.Authentication.OpenIdConnect

这些正在从共享框架中提取出来，并将作为 NuGet 包提供。 这些程序集依赖于尚不符合共享框架指南的 IdentityModel API。 我们已经开始与 IdentityModel 团队合作，并考虑在未来将它们放回共享框架中。 cref https://github.com/aspnet/AspNetCore/pull/6035

更新原始帖子以包含 Microsoft.AspNet.WebApi.Client。 参见https://github.com/aspnet/AspNetCore/pull/6552#issuecomment -453177732。

我经常感到困惑，因为这是我需要包括的内容。

谈论 Visual Studio - 我是否应该打开Microsoft.AspNetCore.App节点并交叉引用那里的所有内容与我可能单独安装的内容？

我正在打扫房间，看到我有这些包裹。 那么哪些是多余的呢？

<PackageReference Include="Microsoft.ApplicationInsights.AspNetCore" Version="2.6.0-beta2" />
<PackageReference Include="Microsoft.AspNetCore.App" />
<PackageReference Include="Microsoft.AspNetCore.NodeServices" Version="2.2.0" />
<PackageReference Include="Microsoft.AspNetCore.SpaServices.Extensions" Version="2.2.0" />
<PackageReference Include="Microsoft.EntityFrameworkCore" Version="2.2.1" />
<PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer" Version="2.2.1" />
<PackageReference Include="Microsoft.EntityFrameworkCore.Tools" Version="2.2.1">

我很惊讶地看到现在甚至包括 SpaServices 和 EntityFramework 工具（我以前没有意识到 - 而且很棒） - 但我也有一些旧的 2.2.1 参考，它们无济于事。

重点是 - 是否可以与 Visual Studio 团队进行一些更好的协调工作，以确保 IDE 在理解这些大型包并告诉我可以安全删除某些内容时更智能一点 - 然后在 v3 中告诉我我需要添加它又回来了;-)

@simeyla感谢您的反馈。 您所说的与主题有关，但这并不完全是该线程的内容。 优化包引用的工具将是一个新的 Visual Studio 功能。 此功能通常很有用，不仅适用于这种情况，因此我建议将此反馈直接发送到 Visual Studio。 在 VS 中，使用“帮助 > 发送反馈...”。 如果您在创建帖子后分享链接，我可以在内部将其转发给我们在 VS 上工作的同行团队。

在 3.0 中，我们将完全消除 Microsoft.AspNetCore.App 元包，并对我们提供的包进行大量调整。 我们已经开始记录如何从 2.x 升级到 3.0 ，并将在我们最终确定 3.0 中发布的程序集列表时继续更新此文档。

移至“讨论”里程碑，因为此项目不跟踪任何工作，而是我们将更新它作为实施更改的详细信息。

将Microsoft.Extensions.DependencyModel到列表中。 已更改为https://github.com/aspnet/AspNetCore/pull/10271 的一部分

在这里提问@natemcmaster @DamianEdwards ，提到了具有在本地构建所需的所有模板的模板。 有了这个想法和 Auth 库的删除，这是否意味着任何 auth 模板都不会在 3.0 中离线构建？ 我知道没有 auth 库可以离线工作，但是如果我没有 nuget 缓存，理论上我可能会在离线时新建一个新的 auth 模板后构建失败。 这似乎是一次糟糕的经历。

是的，这是这种变化的结果之一。 从预览版 6（即将推出）开始， dotnet new mvc 、 dotnet new razor 、 dotnet new web和其他没有任何 PackageReferences，因此它们不应该受到影响，但需要指定其他选项，如--auth individual可能会导致存在需要下载包的 PackageReference。

我们在这里进行了有意的权衡。 尽管具有 PackageReference 的模板不会在干净的机器上离线恢复，但我们也避免了尝试制作预先填充的离线 NuGet 缓存所带来的许多问题（对于初学者，请查看 https://github.com/dotnet/ dotnet-docker/issues/237、https://github.com/NuGet/Home/issues/6309 和 http://blog.ctaggart.com/2019/03/using-nuget-lock-file-for-reproducible .html）。

@natemcmaster完全理解，我明白了推理，只需要有据可查，否则在最初的 3.0 版本中会出现大量问题，人们说dotnet new webapp --auth Individual无法构建。

谁能告诉我为什么 Microsoft.AspNetCore.Authentication.JwtBearer 编译时依赖于 .netcoreapp3.0？ 它不能在 .netstandard2.x 上吗？ 我想在类库中使用它，并且我喜欢将我的类库全部保留为 .netstandard

@buvinghausen https://github.com/aspnet/Announcements/issues/324

@Pilchie我认为这个问题值得在 ASP.NET Core 3.0 的文档中<PackageReference>以补偿移出 Microsoft.AspNetCore.App 的 API。

@Bomret我们检查

我们当然不会，而且我知道其他商店中有很多人将 .net core 用于无服务器应用程序、Web apis 等，而我们对 MVC 的需求绝对为零。

结束，因为我们今天已经发布了 3.0。

我们需要将此列表移至文档

@davidfowl已添加： https: //docs.microsoft.com/en-us/aspnet/core/migration/22-to-30 = aspnetcore-3.0 = visual-studio#remove -obsolete-package-references

@pranavkm该列表实际上恰恰相反：不再是包但可能仍在共享框架中的东西。

这是关于从共享框架中删除的内容，但现在可能仅作为包可用。

@scottaddie这是我们需要在 ASP.NET Core 库创作文档中引用的列表。

@DamianEdwards这个 - https://docs.microsoft.com/en-us/aspnet/core/migration/22-to-30?view=aspnetcore-3.0&tabs=visual-studio#add -package -references-for-removed - 组件？

就是那个 ：）

迟到了，但这并不像是在帮助我实现简化开发的目标。

a) 现在看来，如果对 AspNetCore 组件（例如 SignalR）进行改进，那么我们需要等待 Microsoft.AspNetCore.App 的新“dotnet 包”发布以使用它，并附带所有内容那个包里还有吗？
b) 不能再在 netstandard 类库（例如，Auth 中间件）中为 AspNetCore 创建实用程序类。 现在类库需要是 netcoreapp3.0 来容纳这些东西。 这意味着将我们的实用程序类库拆分为 netstandard / netcore 实现。
编辑：c) 如果我执行<Project Sdk="Microsoft.NET.Sdk.Web">我如何实际定义我正在使用的包的版本？ 显然，我们希望在更新 dotnet 后在不同的分支上进行可重现的构建。

a) 现在看来，如果对 AspNetCore 组件（例如 SignalR）进行改进，那么我们需要等待 Microsoft.AspNetCore.App 的新“dotnet 包”发布以使用它，并附带所有内容那个包里还有吗？

SignalR 与 AspNetCore 的其余部分按相同的时间表发布，因此这里没有时间表更改。

SignalR 与 AspNetCore 的其余部分按相同的时间表发布，因此这里没有时间表更改。

所以这只是一个不好的例子？ 是否可以对所有其他已删除的 NuGet 包说同样的话？

SignalR 与 AspNetCore 的其余部分按相同的时间表发布，因此这里没有时间表更改。

所以这只是一个不好的例子？ 是否可以对所有其他已删除的 NuGet 包说同样的话？

我想是这样。 所有 .NET Core 和 ASP.NET Core 组件都使用相同的发货计划。 如果没有，那么它就必须用自己的包裹运送。

我想是这样。 所有 .NET Core 和 ASP.NET Core 组件都使用相同的发货计划。 如果没有，那么它就必须用自己的包裹运送。

你的话我记住了。 我没有任何具体的反例。 在过去更新 AspNetCore NuGet 包时，它只是没有“感觉”那样。