aspnetcore 🚀 - 新的 ASP.NET Core 2.0 包不能再在 .NET 桌面上使用

这将是一个非常奇怪和糟糕的改变。我已经编写了很多纯 netfx 的 asp.net 核心代码，不想看到投资浪费。更一般地说，在可预见的未来，.NET 客户将需要能够在 ASP.NET Core 和桌面代码之间进行互操作——想象一下使用 Active Directory 或 Office COM 自动化的 web 应用程序，或者使用一些基于 System.Drawing 的缩略图库，或与 WPF 应用程序共享代码。想到很多这样的场景是微不足道的，我希望我们只是误解了正在发生的事情。

gulbanana 于 2017-05-05

👍5

我们目前使用的是 AspNetCore 1.1.1 - 即“当前”支持分支。如果我们由于对 Net4XX 的依赖而无法迁移到 2.0，这是否意味着当 2.0+3 个月下降时我们将不受支持？

ctolkien 于 2017-05-05

👍9

我们结合使用 WPF 和 ASP.NET Core，并在这两种情况下都以完整框架为目标。
所以我猜在可预见的未来不会有 2.0？

MJomaa 于 2017-05-05

但是完整的框架 4.6.1 会支持 netstandard 2 吗？我错过了什么吗？（https://docs.microsoft.com/en-us/dotnet/articles/standard/library）

这不是当前的工具没有更新吗？

aL3891 于 2017-05-05

完全没问题，并且有望看到 asp.net 核心在 net标准2 上运行。令人担忧的是这种迁移到 net core app2.0 的前景，这意味着不再能够在 asp.net 中使用遗留代码核心网站

gulbanana 于 2017-05-05

👍15

哦，这是个问题.. 我想虽然 netcore2 中允许您引用旧程序集的 compat shims 减轻了它的影响，但这仍然意味着将所有项目移植到新项目系统和许多其他工作..

很高兴听到团队对此进行推理

aL3891 于 2017-05-05

哦，所以你认为 netcoreapp2.0 项目将能够简单地引用 netfx 库，这要归功于类型统一？这可以解释很多。如果是这样，我的问题是，当在 Windows 上但在核心 CLR 上运行时，实际上有多少代码可以工作。

gulbanana 于 2017-05-05

哇。这对我们来说完全是一个障碍，并且基本上确保我们在可预见的未来永远无法更新这些包。我们甚至可能需要将我们的 MvcCore 项目迁移回 Mvc，因为我们目前无法绕过针对 net462+ 的问题。

nphmuller 于 2017-05-05

👍3

我也对此非常好奇。我真的希望这是一个中间（和短暂的）步骤或严重的误解。对于我们的大多数应用程序来说，它肯定会阻碍采用。

将所有内容迁移到 Core 对于现有的大型代码库（无需停止开发人员）来说太过分了，迁移到新的 ASP.NET 类（HttpRequest、控制器等）作为我们主要项目的中间步骤。

也许@DamianEdwards或@davidfowl可以在这里评论计划？我也很难找到任何额外的推理。

NickCraver 于 2017-05-05

👍5

我明白为什么这最初是一个可怕的 WTF 时刻。让我解释一下，因为它不像看起来那么奇怪。

您说 .NET 客户将需要互操作。完全同意。
- 我们可以在 ASP.NET Core 2.0 和 EVERYWHERE 之间共享 netstandard 库。
- 由于类型转发和 netstandard20，我们甚至可以从 ASP.NET Core 2.0 引用许多 net461+ 程序集
您说 WebApps 可能需要使用：
- AD – 完全是，如果您想直接调用 LDAP，这是一个差距。您现在当然可以针对 Windows Auth 进行身份验证。我们计划在夏季时间框架内专门为 Core 2.0 提供 DirectoryServices 命名空间
- 绘图 - 完全，这是一个差距。我们计划在夏季时间框架内为 Core 2.0 提供此功能。在此之前，这些 netstandard 选项还存在 ImageSharp、ImageResizer、Mono 选项等
- COM 自动化——这在 Core 2.0 下是不可能的，但如果你想伤害自己，你当然可以 PInvoke。如果您真的想伤害自己，您也可以将 WebAPI 本地化到 net461+ 进程。
- 与 WFP 应用程序共享代码 - 是的。 netstandard2.0 完全可以。
这是一个奇怪的改变。
- 感觉是这样，但是……

这样想吧。 WPF 不是 netstandard2.0，它知道它在 net461+ 上，这没关系。它已经过优化，但它可以引用 netstandard 库。 ASP.NET Core 2.0 针对 Core 2.0 进行了优化，但它可以引用共享库。 Xamarin 也是一样。

.NET Core 并存，而且发展迅速。它比 .NET (Full) Framework 移动速度要快得多，这很好。通过在 .NET Core 2.0（请记住，它是 .NET Standard 的超集）之上构建 ASP.NET Core 2.0，这意味着可以比 NetFx 甚至 Netstandard 更快地构建东西。

在开发速度和创新方面，NetCore > Net Standard > NetFx。

重点是，如果你在做新工作，netstandard20。如果您有较旧的 net461+ 库，其中大部分可以在 ASP.NET Core 2.0 下引用。

在 .NET Framework 上运行的 ASP.NET Core 1.1 将在我们发布 2.0 后的一年内得到全面支持。至少到 2018 年 7 月，该工作量将得到全面支持。

.NET Core 2 中剩余的较大差距是 System.DirectoryServices 和 System.Drawing。我们正在努力开发一个 Windows 兼容包，它将在今年夏天在 Windows 上启用 .NET Core 上的这两个兼容包。

我们需要大家清楚地列出/理解为什么您认为需要 ASP.NET Core 2.0 才能在 net461+ 上运行。

shanselman 于 2017-05-05

👍110 😕35 👎8 ❤5

我认为 .NET Standard 2.0 完全是关于兼容性和互操作性的，它弥合了每个人都在等待的 .NET Core 和 .NET fx 之间的差距——这似乎扼杀了这一点。

无论出于何种原因，都会有很多客户拥有需要 .NET 4.x 的依赖项，无论是自定义外部依赖项、商业组件、遗留库依赖项等。

客户是否打算创建在 Desktop CLR 上运行的 ASP.NET Core 2.0 应用程序，以便他们可以引用现有的 .NET 4.x 部门？

mythz 于 2017-05-05

👍29

@shanselman感谢您的回复-那里有很多很好的例子。

关于图书馆的后续行动：
所有的抽象库都会保持交叉编译吗？例如，如果我使用HttpRequest ，则在您使用的 ASP.NET Core 版本（现在至少可以清晰地映射到 TFM）上维护 1.x 和 2.x 构建将是一些事情我宁愿避免......所以我希望抽象将保留在netstandard上。这是总体计划吗？

我们已经为依赖 ASP.NET/MVC 的东西维护了多个变体，因为System.Web的HttpRequest完全不同，所以这完全是另一个库（例如MiniProfiler vs . MiniProfiler.AspNetCore )。我只是想确保我们牢记我们正在为任何 lib 作者加载维护的变体数量，如果他们的依赖关系离开netstandard ...并希望一起避免那种头痛。

NickCraver 于 2017-05-05

👍5

我很高兴这看起来并不像看起来那么重要，感谢您的详细说明。

我确实有两个问题/疑虑：

听起来从 ASP.NET Core 使用 .NET Framework 库应该有最小的摩擦。那太棒了！反过来呢？可能有 .NET Framework 或 netstandard 库和应用程序嵌入来自 Mvc 和其他支持 ASP.NET Core 库的部件或组件（我知道是因为我有几个）。那些会坏的，对吗？有没有关于如何解决这种情况的提示？如果 netstandard 库不能再使用 ASP.NET Core 库，这对于嵌入式 ASP.NET Core 场景来说似乎是一件大事。
从非技术的角度来看，这似乎会引起很多混乱。除了在 GitHub 上活跃的人之外，在 Twitter 上关注等等。围绕不同平台等已经存在很多混乱。我可以看到开发人员只是部分关注或刚刚起床当他们去使用 ASP.NET Core（可能遵循一个过时的教程）并且无法让它在他们的 .NET Framework 平台上工作时，速度变得非常沮丧。不知道可以做些什么，如果有的话。

daveaglick 于 2017-05-05

👍10 🎉1 👎1

由于类型转发和 netstandard20，我们甚至可以从 ASP.NET Core 2.0 引用许多 net461+ 程序集

不幸的是，这并不意味着为完整框架编译和设计的库可以在 .NET Core 上运行（风险很高，运行时会爆炸！）。

.NET Core 2.0 中重新引入的许多“旧”API 是永远不会（功能上）工作的存根。更不用说还有很多缺失的 API，甚至是故意从 .NET Core 中排除的整个领域（IdentityModel、WCF 服务器、远程处理、完整的 AppDomain 支持等）

试图说服人们他们可以“安全地”将他们的带有 .NET 桌面应用程序的 ASP.NET Core 1.0 迁移到带有 .NET Core 的 ASP.NET Core 2.0 是 - 恕我直言 - 一个谎言。

.NET Core 并存，而且发展迅速。它比 .NET (Full) Framework 移动速度要快得多，这很好。通过在 .NET Core 2.0（请记住，它是 .NET Standard 的超集）之上构建 ASP.NET Core 2.0，这意味着可以比 NetFx 甚至 Netstandard 更快地构建东西。

我不相信这是（大多数）人们正在寻找的。许多人不需要快速移动的库，他们需要稳定的东西，可以优雅地集成到他们的旧东西中，而不冒破坏一切的风险。

kevinchalet 于 2017-05-05

👍62

@daveaglick

正确的是，没有从net461甚至netstandard2.0引用netcoreapp2.0的隐式能力。这座桥是单向的。您始终可以通过为包回退指定 TFM 来解决它，但这显然是一个逃生舱，而不是受支持的场景（尽管它足以解除对许多人的阻止）。对我们来说，在更大的堆栈之外支持 ASP.NET Core 的子系统是一项不小的工作（这就是目标netstandard所暗示的）。
混乱的可能性是双向的。例如，我们收到很多反馈，“ASP.NET Core”可以在 .NET Framework（不是.NET Core）上运行这一事实令人困惑。此更改有效地使 ASP.NET Core 成为 .NET Core 堆栈的一部分，这意味着如果您使用的是 ASP.NET Core，那么您使用的是 .NET Core。

DamianEdwards 于 2017-05-05

😕9 👍8

@shanselman顺便说一句，您没有说为什么不能选择交叉编译。可以从仅netcoreapp2.0 API 中受益的 ASP.NET Core 组件可以同时具有net46 / netstandard1.x / netstandard2.0和netcoreapp2.0 TFM 和仅使用 .NET Core 制作新的酷/快的东西。

kevinchalet 于 2017-05-05

👍1

@NickCraver目前该计划不包括保留针对netstandard的 *.Abstractions 包。这种分离并不像全面的那样干净。但是，对于尝试像您建议的那样进行迁移的人来说，使用包目标回退应该可以让您到达那里（但我可能会误解您）。

此外，您认为干净的 TFM 拆分是正确的，并且是该计划的一个优势，因为单个包现在可以使用 TFM 作为支点同时针对 ASP.NET Core 1.x 和 2.0+。

DamianEdwards 于 2017-05-05

👍2 👎1

我一直在玩弄“混合应用程序”的想法。例如，暴露 Web API 的 WPF 应用程序或同时提供 REST API 和 WCF 端点的服务器（这可能是为了与早期客户端兼容）。这种变化使这些场景变得不可能，并使 ASP.NET Core 仅适用于新应用程序，而不是“只是一个库”。

ap0llo 于 2017-05-05

👍2

@PinpointTownes正如@shanselman所说，我们对客户需要继续直接针对 .NET Framework 的具体要求和障碍非常感兴趣。到目前为止，我们在这艘船上与客户的合作表明System.DirectoryServices和System.Drawing以及 1 号和 2 号阻滞剂，我们有计划解决这个问题。除此之外，我们正在查看反馈并进行评估。

交叉编译是必须与客户和产品需求平衡的开销。这就是为什么我们希望获得此反馈，以便在我们继续发展 ASP.NET Core 向前发展时，我们可以更具体地定义我们的客户和我们的环境。

DamianEdwards 于 2017-05-05

@DamianEdwards感谢您的进一步澄清。 netstandard -> ASP.NET Core 库对我来说很重要。我在几个 netstandard 库中嵌入了 Kestrel（看起来也将迁移到 netcoreapp）。我还在几个地方嵌入了 Razor，而且我知道您正在开发新的更加模块化的版本，但如果它也只针对 netcoreapp，那就会受到伤害。还有大量的库是 ASP.NET Core 的“一部分”，但在它之外还有很多实用程序。

换句话说，我更关心消除 netstandard 库使用 ASP.NET Core 包的能力，而不是相反。似乎这正在从考虑中删除一整类用例。

daveaglick 于 2017-05-05

👍19

@daveaglick Razor 本身（引擎）将继续以netstandard为目标。同样，在不同平台上支持大型复杂图（如 ASP.NET Core 2.0）的特定子系统是有成本的。对于诸如嵌入之类的事情，还有其他选项（源嵌入、复制等），但当然它们也有自己的取舍。

在不同类别的用例方面肯定会听到您的声音，在设计和交付像我们这样的堆栈时，我们确实需要考虑不同的客户群。

DamianEdwards 于 2017-05-05

我在这里分享@daveaglick的担忧：想要使用最新 API 的 ASP.NET Core 是完全可以理解的，但对于其他所有下游需要相同的东西来说，这会变得有点混乱。在稳定版或升级版 1.0 之后，您别无选择，您乘坐的是最快的火车netcoreapp2.0 ，这是唯一的选择。如果在不让用户消费netcoreapp2.0的情况下无法消费所有位（甚至是基本抽象），这意味着整个库线实际上没有netstandard2.0 ......每个人这取决于他们。

我得到了核心应用程序堆栈的移动，但我不一定同意特别移动的抽象。抽象的要点之一是避免像这样的紧密耦合，至少从我作为消费者的角度来看是这样。我很想看到一些示例，其中netstandard2.0没有所需的 API，但netcoreapp2.0有 - 那里有一些示例吗？这主要是围绕方法参数中的新类型吗？我不怀疑有充分的理由，我只是很好奇 - 查看示例将有助于显示我们几乎没有日常洞察力的维护成本。

Kestrel 案例更复杂，但我确实看到了将它放在最新 API 集上的论点。考虑到 Kestrel 正在推动的工作，我认为将不断为Kestrel 创建新的 API。

NickCraver 于 2017-05-05

👍25

@PinpointTownes正如@shanselman所说，我们对客户需要继续直接针对 .NET Framework 的具体要求和障碍非常感兴趣。

作为一名顾问，我帮助一群客户将他们的应用程序迁移到 ASP.NET Core，我经常不得不以 .NET Desktop 为目标，以便能够使用依赖于IdentityModel / WCF或依赖于AppDomain的第三方（闭源）库支持。

在 ASP.NET Core 2.0 中没有这些东西将是他们的主要障碍。

即使有 API，也有一些库无法在 .NET Core 上运行，因为它们在功能上会有所不同。这是我见过很多次的具体案例：

在 .NET Core 上， RSA.Create()在 Windows 上返回一个RSACng实例，但在 .NET 桌面上，返回一个RSACryptoServiceProvider实例。然而，许多库 - 包括 BLC 本身 - 尝试将RSA转换为RSACryptoServiceProvider ，这在 .NET Core 上总是会失败，因为RSACng不能转换为RSACryptoServiceProvider 。

kevinchalet 于 2017-05-05

👍17

@NickCraver特别是哪些抽象？仅移动抽象的问题在于，接下来您最终也会想要建立在这些抽象之上的所有内容（除非您实际上是在说您只需要 Microsoft.AspNetCore.Http.Abstractions 而无需其他任何东西）

davidfowl 于 2017-05-05

@davidfowl是的，只有抽象：例如 HTTP、托管、HTML 和日志记录。看起来Microsoft.Extensions.*已被较早的评论所涵盖，其中大部分。这些就是我今天要与之交互的那些。

举个具体的例子：MiniProfiler 中间件只回复抽象（链接）

如果您在顶部使用 MVC 等，那么无论如何您都在使用netcoreapp2.0 ，这就是它（和 IMO，这很好）。但目前我可以自由地在共享的地方逻辑拆分 API，并且因为它们是抽象的，所以很容易做到这一点。我非常喜欢当前的分裂，请不要不必要地锁定它。

NickCraver 于 2017-05-05

👍7

呵呵。作为一名顾问，我肯定听说过“什么？ASP.NET Core 在桌面 .NET Framework 上运行！？” 问了好几遍。事实上，“ASP.NET Core”的名称中确实包含“.NET Core”，这真的很不幸。

无论如何...就像我在 .NET Core 刚开始时（“全新”开始）时放弃过时/遗留/损坏的 API 的粉丝一样，我也很喜欢这种更改，以便获得更快、更精简的框架具有更多功能和更高的创新率。

话虽如此，我也很同情那些由于某种原因无法在明年 6 月之前将所有代码迁移到 .NET Core 的开发人员。

这包括我当前的客户端，它有一个非常大的遗留库/框架，以 .NET Framework 为目标，目前正在并行开发的多个 ASP.NET Core 项目使用。当这些系统投入生产时，将几乎没有时间来 a) 将所有内容移植到 .NET Core，或 b) 在 ASP.NET Core 1.x 不受支持之前将所有内容迁移到完整框架 ASP.NET。

这里一年的支持真的够吗？我可以想象还有其他类似的案例......

khellang 于 2017-05-05

👍11

@khillang如前所述，他们将能够继续引用针对 .NET Framework 的库/框架，并且假设他们调用的 API 是netstandard2.0闭包的一部分，这将工作得很好。你知道他们是否依赖那个空间之外的东西吗？这就是我们真正希望得到反馈的地方，这样我们就可以评估移植这些 API 的优先级（例如System.DirectoryServices和System.Drawing ）。

DamianEdwards 于 2017-05-05

因此，对于当前的 Windows 服务或 WPF 桌面应用程序来说，托管 Web api（比如通信层）甚至即将推出的 asp.net 核心套接字将变得不可能？（支持的版本）。

dasMulli 于 2017-05-05

👍5

我想将会有一份清单列出曾经是netstandard1.x现在是netcoreapp2.0的东西

我浏览了存储库，似乎 MVC 特定的东西是netcoreapp2.0但 HttpAbstractions、日志记录、配置等仍然是netstandard或者还有更多的变化吗？

adamhathcock 于 2017-05-05

@NickCraver我看到您正在使用扩展，但仍在使用 System.Web。你有计划用System.Web.HttpContext填充Microsoft.AspNetCore.Http.HttpContext #$ 吗？你知道你需要多少 API 吗？

如果您在顶部使用 MVC 等，那么无论如何您都在 netcoreapp2.0 上，这就是它的本质（和 IMO，这很好）。但目前我可以自由地在共享的地方逻辑拆分 API，并且因为它们是抽象的，所以很容易做到这一点。我非常喜欢当前的分裂，请不要不必要地锁定它。

不过，我不是在谈论 MVC，我只是在谈论在底层抽象之上公开更多功能的其他助手。我们选择的“抽象”模式的最大价值在于其他东西可以建立在它们之上，而不是抽象本身。我的直觉告诉我，如果我们制作 ASP.NET 抽象网络标准，那么我们最终将不得不制作所有中间件网络标准。

一旦我们将 API 移植过来， @dasMulli Windows 服务就可以工作（在 .NET Core 上也有支持 Windows 服务的开源库）。

WPF桌面应用程序？（支持的版本）。

是的。这将不再是默认设置。 .NET Core 2.0 不再支持开箱即用。

davidfowl 于 2017-05-05

👍1

@davidfowl我不确定你在那里看过正确的作品：

但仍在使用 System.Web

...由于这种拆分，不在同一个库中。为了实现最小的开销而不是消费者的大量依赖项，对于 ASP.NET MVC < 6 (System.Web) 和 $# MiniProfiler MiniProfiler.AspNetCore / MiniProfiler.AspNetCore.Mvc (很多 NuGet ）。

我认为您说的是MiniProfiler.Shared上的System.Web残留物-我一直在等待清理这些残留物，直到昨晚在框架程序集上修复了 NuGet 问题。我只是将其删除以清除问题。

NickCraver 于 2017-05-05

@DamianEdwards我不是 100% 关闭netstandard2.0 ，但我很乐意（在他们允许的情况下）运行可移植性分析器并分享结果。可移植性分析器仍然是最新的东西吗？

khellang 于 2017-05-05

👍1

ASP.Net Core 正在迅速成为新的 Python 3*；只会更糟。这对我来说似乎是一个错误的方向。这只是意味着大量的场景将迫使开发人员在未来很多年在“旧平台”上维护（并编写新的）代码，而不是移动。 “更快的发展”似乎不是一个很好的论据，如果它意味着你会“更快”地到达一个更糟糕/不合适的地方。

*我喜欢 Python 3，但它已经发布了将近十年，Python 社区仍然支离破碎

jhurdlow 于 2017-05-05

👍27 👎6

只是要明确一点 - 是否有任何技术障碍（花哨的性能）或者这只是为了节省未来维护兼容性的成本？
我想我们大多数人都知道这一举措会到来，但没有人预料到会这么快......考虑到过渡时间仍在继续（比如库正在被移植，.net 标准 2.0 即将到来，但还没有为它构建库） - 为至少一个版本（例如 2.0，而不是 2.1）保留 net* 支持会很棒。

dasMulli 于 2017-05-05

@shanselman我明白你的观点，我个人什至同意，但很多人不会这么看。

主要问题不是从核心调用 net46 程序集，在大多数情况下，compat shims 都会处理这个问题。问题是现有的 net46 代码和在 46 上运行的 asp.net core 1.* 代码。正如有人提到的，netstandard 的全部目的是允许包括 asp.net 在内的代码在任何地方运行，这感觉就像一个步骤对某些人来说，远离这一点，甚至可能是这种愿景的失败。

我认为问题不在于人们不想_迁移到网络核心。问题是组织、经理、CTO 等必须确信这样做的成本/收益是值得的。移植时间不仅足以消耗到交付中，而且还引入了回归等风险。

换句话说，阻止人们移动的并不总是技术原因。我什至会说它很少见，_技术上_几乎任何项目都可以实现这一目标。但是激发成本/交付滑坡，这就是问题所在。这可能很难卖，我不得不做几次。在那些情况下，能够说“但你可以在完整的框架上运行”一直是推动这一举措的一种方式

如果你想伤害自己

这正是它。 Net46 开发人员和管理人员不会那样看，他们会认为是_你_，微软，为了跟上最新版本而想要伤害他们。 “好吧，那就别动了”有人可能会说，但在 asp.net core 1.x 的支持下，他们不得不这样做，至少从经理的角度来看，他们必须负责，如果错误导致停机或信息丢失。（即使框架不负责）

许多真正推动 asp.net core 1.1 的开发人员也会感到被背叛，他们现在无法在没有核心的情况下迁移到 2.0。这可能是合理的，也可能不是合理的，但我只是告诉你，很多人都会有这种感觉，他们将是那些必须对他们更保守的同事负责的人

这些有关系吗？ asp.net core2/dotnet core2会因此“死”吗？不，但它会减慢采用速度并破坏生态系统，这真的很可悲。我希望人们能够使用 2.0 中的所有这些很棒的东西，并将交叉编译削减到网络标准会影响到这一点。当然，大多数在这些 repos 中闲逛的人都不会有问题，它的 Joe 和 Jane dev 甚至更重要的是，他们的经理就是问题所在。

@达米安爱德华兹
我同意这一直是混乱的根源，我不得不解释很多次，但结果总是把一个失望的开发者变成一个兴奋的人，因为他们认为他们无法使用新的很酷的东西但事实证明他们可以。

总结一下，我敢肯定这个决定不是轻易做出的，但如果你必须这样做，我认为你必须非常_非常_小心消息传递。你必须证明迁移到 asp.net 核心，尤其是从 1 开始。 net46 上的 x 是_超级_简单且超级抛光的。从 net46 引用其他 netstandard 库作为项目引用和其他方面的故事必须坚如磐石。我认为你需要明确地展示/解决这个问题，以避免人们吓坏

aL3891 于 2017-05-05

👍56 ❤14

@khillang为 Portability Analyzer 问题分页@terrajobst 。

DamianEdwards 于 2017-05-05

@khillang

是的，我们刚刚更新了 2017 年的 VSIX，但我只是使用此处的命令行版本。

terrajobst 于 2017-05-05

@NickCraver当然，您可以编写一个针对 netstandard 的中间件，如果 ASP.NET Core 支持 netcoreapp2.0，这对您作为库作者有什么好处。

@aL3891很棒的总结！我们面临的一个大问题是我们如何利用新的 API 来处理同样在 netstandard 中的东西。 .NET Core将获得我们实现新功能所需的新 API（想到的是 SSLStream ALPN 支持 Kestrel 中的 HTTP2 支持）。因此，您可能会争辩说我们继续使用 netstandard 并不断使用最高版本（.NET Framework 尚不支持该版本），但我们会在同一条船上。

davidfowl 于 2017-05-05

我们面临的一个大问题是我们如何利用新的 API 来处理同样在 netstandard 中的东西。 .NET Core 将获得我们实现新功能所需的新 API（想到的是 SSLStream ALPN 支持 Kestrel 中的 HTTP2 支持）。

根据https://github.com/dotnet/corefx/issues/4721 ， SslStream的 ALPN 支持将无法用于 .NET Core 2.0。假设这最终在几个月后实施，这是否意味着在瞄准netcoreapp2.0 TFM 时可以使用它？在这种情况下，如果我决定发布一个基于netcoreapp2.0的库，如果我的用户使用较旧的 .NET Core 运行时，该库使用不属于初始netcoreapp2.0形状的新 API，会发生什么情况? 它会崩溃吗？或者netcoreapp2.x是否会与netstandard1.x保持一致，如果不增加 TFM 版本就无法更改其合同？

kevinchalet 于 2017-05-06

@davidfowl用于任何堆栈和测试的其他实现。而且因为抽象的方式（不需要 MVC）作为 2 个库之间的体面拆分，而不是“假设每个人都有 MVC 并想要所有依赖项”。

如果抽象实际上不是抽象并且与 ASP.NET Core 本身紧密耦合，我们为什么不直接删除这些包呢？这是一个诚实的问题，因为如果这是整体关系目标，那会让生活更轻松、更清晰。如果它们有效地与简单的实现/使用相关联，我试图理解将抽象作为单独的包的意义。我认为微软以外的任何人都不想或有资源专门用于竞争netcoreapp2.x网络服务器（很高兴在那里得到纠正！）。

您能否阐明抽象在netcoreapp2.x世界中的意义是什么？或者如果有计划在 2.0 中简单地弃用它们？

NickCraver 于 2017-05-06

👍1

根据 dotnet/corefx#4721，对 SslStream 的 ALPN 支持不会为 .NET Core 2.0 做好准备。假设这最终会在几个月后实现，这是否意味着在针对 netcoreapp2.0 TFM 时可以使用它？在这种情况下，如果我决定发布一个基于 netcoreapp2.0 的库，该库使用不属于初始 netcoreapp2.0 形状的新 API，而我的用户使用的是较旧的 .NET Core 运行时，会发生什么情况？它会崩溃吗？或者 netcoreapp2.x 是否会与 netstandard1.x 保持一致，后者的合约不能在不增加 TFM 版本的情况下更改？

ASP.NET 版本 x 将与 .NET Core 版本 x 保持一致。 TFM 将更新以与 .NET Core 的每个版本保持一致。它是一个单一的产品，最终可以这样对待。这是我们在上面提到的@DamianEdwards所做的主要简化之一。我们不会在不更改 TFM 的情况下通过在核心中添加新 API 来破坏人们构建库的工作。

@尼克克拉弗

对于任何堆栈和测试的其他实现。

还有哪些实现方式？是否还有其他实现 ASP.NET Core 的堆栈部分。

如果抽象实际上不是抽象并且与 ASP.NET Core 本身紧密耦合，我们为什么不直接删除这些包呢？这是一个诚实的问题，因为如果这是整体关系目标，那会让生活更轻松、更清晰。如果它们有效地与简单的实现/使用相关联，我试图理解将抽象作为单独的包的意义。我认为微软以外的任何人都不想或有资源专门用于竞争的 netcoreapp2.x Web 服务器（很高兴在那里得到纠正！）。

您能否阐明在 netcoreapp2.x 世界中抽象的意义何在？或者如果有计划在 2.0 中简单地弃用它们？

我们可以将所有内容都放在一个程序集中，但重构使我们能够获得未来的灵活性，如果我们这样做的话，我们将不会拥有这种灵活性。它甚至开辟了拥有其他实现的可能性，并且从长远来看并没有真正排除它。

简单地说，抽象是关于减少依赖的数量，而不是关于平台的可移植性。

davidfowl 于 2017-05-06

我们不会在不更改 TFM 的情况下通过在核心中添加新 API 来破坏人们构建库的工作。

你们说你想选择netcoreapp2.0 - 只是因为它移动得更快 - 与 .NET Desktop 和扩展的 .NET Standard 相比 - 但是定位netcoreapp2.0而不是netstandard2.0如果不更改 TFM 就无法从新的 .NET Core API 中受益？（例如netcoreapp2.1 ）

kevinchalet 于 2017-05-06

你们说你想选择 netcoreapp2.0-only 因为它移动得更快 - 与 .NET Desktop 和扩展的 .NET Standard 相比 - 但是如果可以的话，瞄准 netcoreapp2.0 而不是 netstandard2.0 有什么意义在不更改 TFM 的情况下不能从新的 .NET Core API 中受益？（例如 netcoreapp2.1）

抱歉，我说错了，我的意思是netcoreapp2.x不是netcoreapp2.0 。

davidfowl 于 2017-05-06

好吧，我现在完全糊涂了。

抱歉，我说错了，我的意思是 netcoreapp2.x 不是 netcoreapp2.0。

我不确定我是否理解。您的意思是 ASP.NET Core 2.1 包和netcoreapp2.1 TFM 之间存在等价关系吗？

kevinchalet 于 2017-05-06

👍2

您的意思是 ASP.NET Core 2.1 包和 netcoreapp2.1 TFM 之间存在等价关系吗？

是的。将 2 视为同一个。见https://github.com/aspnet/Home/issues/2022#issuecomment -299544884

davidfowl 于 2017-05-06

那么是什么阻止您采用类似的模式，但使用netstandard呢？恕我直言，这将是最好的方法：可以通过新的 TFM 采用新的 API，需要支持 .NET 桌面的人仍然可以在完整的框架上运行他们的 ASP.NET Core 应用程序。

ASP.NET Core 2.1/.NET Core 2.1/.NET 桌面 4.7.1 -> netstandard2.1
ASP.NET Core 2.2/.NET Core 2.2/.NET 桌面 4.8 -> netstandard2.2 。

kevinchalet 于 2017-05-06

👍3

@PinpointTownes因为桌面上的 .NET Framework 发布速度不够快，这是大多数 Core 版本控制问题的症结所在。这是一个巨大的链条中的难题。

NickCraver 于 2017-05-06

👍3

.NET Standard 的发展速度与 .NET Core 不同。实际上离它还差得很远。 .NET Standard 的移动基本上将所有平台都抛在了后面，直到它们赶上来，而 .NET Framework 既是移动最慢的，也是最大的。

DamianEdwards 于 2017-05-06

点令牌，虽然我不确定 .NET Framework 应该以多快的速度发布（例如，新的 ECDSA API 在不到一年的时间内从 CoreFX 移植到 NetFX，这对于此类敏感的加密组件来说似乎是一个合理的时间框架）。

交叉编译是必须与客户和产品需求平衡的开销。

如果您有时间，我很想了解更多关于交叉编译造成的开销的确切性质。谢谢。

kevinchalet 于 2017-05-06

👍1

我们需要大家清楚地列出/理解为什么您认为需要 ASP.NET Core 2.0 才能在 net461+ 上运行。要具体，这样我们就可以缩小这些差距，让每个人都取得成功。

目前，我们需要 WCF 客户端库的完整框架版本 - 因为netstandard / netcore版本 (https://github.com/dotnet/wcf) 尚未完成。

ctolkien 于 2017-05-06

如果您有时间，我很想了解更多关于交叉编译造成的开销的确切性质。谢谢。

在不久的将来会有一段时间，我们实际上无法填充诸如 ALPN 对 SSLStream 的支持之类的功能。此外，我们甚至还没有开始将 API 添加到 .NET Core 中，到目前为止，我们已经陷入了将东西移植回 .NET Standard 和 .NET Core 2.0 的困境（.NET Standard 2.0 的全部目的） . 我们将添加新的 API，并最终在第一天在 ASP.NET Core 中使用它们。

目前，我们需要 WCF 客户端库的完整框架版本——因为 netstandard / netcore 版本（https://github.com/dotnet/wcf）还没有接近完成。

@ctolkien这是一个问题，这也是我们首先移植 WCF 客户端的原因。你知道是什么阻碍了你吗？这是帮助我们确定优先级的好机会。

davidfowl 于 2017-05-06

@davidfowl https://github.com/dotnet/wcf/issues/8

可能还有更多，这只是我们在过渡到完整框架 wcf 之前遇到的第一个障碍。

ctolkien 于 2017-05-06

在不久的将来会有一段时间，我们实际上无法填充诸如 ALPN 对 SSLStream 的支持之类的功能。

这怎么成问题？ AFAICT，这里从来没有说过 .NET 桌面和 .NET Core 风格的 ASP.NET Core 必须支持相同的确切功能集。如果由于缺少 API（例如 HTTP 2/0）而导致 .NET 桌面上的某个功能不可用，为什么不将其设为 .NET Core-only 并抛出PlatformNotSupportedException告诉开发人员他正在寻找的功能是无法使用？
这比将所有 ASP.NET Core 包都制作为仅 .NET Core 好得多，尽管它们中的大多数不太可能使用新的 BCL API。

kevinchalet 于 2017-05-06

👎4 👍2

@davidfowl我想一个主要的担心是事情没有得到解决，比如netcoreapp2.3 ，它得到了解决netcoreapp2.4 。如果 ASP.NET Core 专注于最快的火车，那么每个小版本需要多长时间才能得到爱？如果我们必须不断升级，那么每个消费者都必须不断升级。

这对于获得最新最好的东西非常有用，但对大多数公司来说并不是最好的。因此，我们要么必须为每个 ASP.NET Core 使用者使用我们的库维护多个版本（每个次要版本）（不依赖于最新并跟上），要么将用户拖到最新版本以跟上。这对诸如经过验证的环境之类的东西不友好。

除非抽象需要尽快更新（例如？），否则最好将它们断开连接。这样，您就不会在每次升级时拖累整个生态系统。我想我更关心的不是它们会出现在netcoreapp上，而是它们会不断更新并且一切都紧密耦合。

如果抽象将维护每个次要版本并将痛苦（坦率地说）转移到您的身边，我就不那么担心了。你们能在这里详细说明修改的意图吗？

NickCraver 于 2017-05-06

👍5

@PinpointTownes ：

为什么不将其设为 .NET Core-only 并抛出 PlatformNotSupportedException 告诉开发人员他正在寻找的功能不可用？
这比将所有 ASP.NET Core 包都制作为仅 .NET Core 好得多，尽管它们中的大多数不太可能使用新的 BCL API。

Noooooooo，请不要。这是运行时失败，并且是非常不可取的行为。我们希望尽可能多地在编译时保证我们的库可以正常工作。对此有很多争论，这根本不是一条好路。应尽可能避免使用PlatformNotSupported 。

NickCraver 于 2017-05-06

👍46

这是运行时失败，并且是非常不可取的行为。

如果您的程序集尝试使用不受支持的 API，这正是“将 .NET 桌面程序集放在 .NET Core 上”方法会发生的情况，但您将获得MissingMemberException而不是PlatformNotSupportedException 。

使用我的方法，您至少可以使用诸如 Roslyn 分析器之类的东西来定义更好的工具故事，这些工具可以在编译时确定您正在使用的 API 是否受支持。

kevinchalet 于 2017-05-06

👍8

顺便说一句，扔一个PlatformNotSupported真的是一个极端情况。使用交叉编译，最好的选择是从公共合约中简单地排除不受支持的 API。

kevinchalet 于 2017-05-06

@PinpointTownes我也是这么想的，但现实是新平台发布，而且没那么简单。在讨论了很多次之后，我对如何在这里做 compat 有了很大的改变。使用netcoreapp方向允许以次要版本发布修复程序。采用另一种方式意味着您必须等待 .NET Desktop 发布修复程序，这...祝您好运。这是一个非常缓慢的解决方案。

AFAICT，这里从来没有说过 .NET 桌面和 .NET Core 风格的 ASP.NET Core 必须支持相同的确切功能集。如果由于缺少 API（例如 HTTP 2/0）而在 .NET Desktop 上无法使用某项功能，为什么不将其设为 .NET Core-only

前半部分就是netstandard是什么。区别于netcoreapp正是他们在这里所做的。没有故意的例外。这条路线是合适的合同。

当涉及到差距时，您希望朝着可以更快地修复和改进的方向发展，而不是相反。明天可以在库中修复“PlatformNotSupported”异常，而不是等待平台从现在起 3 个月后更新。 .NET Core 可以更快地支持它们，因为它附带了实际代码，而不是大多数时候单独作为转发器。

NickCraver 于 2017-05-06

👍2

[@PinpointTownes] 如果由于缺少 API（例如 HTTP 2/0）而在 .NET 桌面上无法使用某项功能，为什么不将其设为仅 .NET Core 并抛出PlatformNotSupportedException告诉开发人员该功能他要找的不可用？

我们需要在 API 表面和覆盖范围的简单性与开发人员的生产力之间取得平衡。到目前为止，我们主要使用PlatformNotSupportedException来提供与过去兼容的 API 界面。我们不打算使用PlatformNotSupportedException作为一种方式来提供不相交的功能集向前发展。相反，我们要么放弃对不具备这些功能的 .NET 平台版本的支持，要么将该功能作为一个独立的 NuGet 包提供，但它本身并不在所有地方都受支持。

terrajobst 于 2017-05-06

遵循 netcoreapp 方向允许以次要版本发布修复程序。

这与 1.0 方法有何不同？ @davidfowl说新的 API 需要新的 TFM，这意味着你必须选择退出 LTS 才能获得依赖于新的 .NET Core API 的修复。并不是一个理想的情况。

区别于 netcoreapp 正是他们在这里所做的。

差异化完全没问题，我绝对同意 .NET Core 应该是 ASP.NET Core 的首选目标。但这并不意味着完全放弃 .NET Desktop，尤其是在存在交叉编译等替代方案的情况下。

我们需要在 API 表面和覆盖范围的简单性与开发人员的生产力之间取得平衡。

当然。但是您还需要平衡这一事实，即为 .NET 桌面开发并使用 .NET Core 上不可用的功能的旧库应该在 ASP.NET Core 2.0 中正常工作，就像它们在 1.0 中一样。

kevinchalet 于 2017-05-06

相反，我们要么放弃对不具备这些功能的 .NET 平台版本的支持，要么将该功能作为一个独立的 NuGet 包提供，但它本身并不在所有地方都受支持。

理论上完全没问题。但问题是目前缺少重要功能的平台是 .NET Core，而不是 .NET Desktop。这可能会在几年内发生变化，但可以肯定的是，人们仍然会发现 .NET Core 2.0 中缺少的功能。

kevinchalet 于 2017-05-06

👍3

可能值得在 dotnet 中拥有一个forward-port存储库，人们可以在其中对他们认为从 .NET Framework 的 .NET Core 中丢失的特定项目发出 api 请求？

那么反馈、审查和指导可以在代码仓库的日常噪音之外进行吗？或一般的 api 审查/规范 repo（有点像 csharplang vs roslyn）

也将是一个很好的选择：“我有转换问题，需要搜索与 X api 相关的问题”而 corefx 对此非常嘈杂。

benaadams 于 2017-05-06

👍7

[@benaadams] 可能值得在 dotnet 中拥有一个转发端口 repo，人们可以在其中对他们认为从 .NET Framework 的 .NET Core 中丢失的特定项目发出 api 请求？

我想说这些只是 CoreFx 中的问题。此外，我们的承诺通常是：如果类型在 .NET Framework 和 .NET Core 之间共享，我们打算将新添加的成员移植到 .NET Framework。在极少数情况下，这可能是不可能的，但关键是它们会被自动考虑。

[@benaadams] 或者一般的 api 审查/规范 repo

不确定是否值得。 API 审查已经有些严厉了；将它们提取到另一个回购似乎放大了这一点。我宁愿我们继续精简 CoreFx，以便添加新的 API 就像在 ASP.NET 中那样简单。

terrajobst 于 2017-05-06

如前所述，他们将能够继续引用针对 .NET Framework 的库/框架，并且假设他们调用的 API 是 netstandard2.0 闭包的一部分，这将工作得很好

@DamianEdwards那些不在 netstandard2.0 关闭中的 API 呢？大多数第 3 方库都是闭源的。我怎么知道每个边缘情况都在 netstandard2.0 的关闭中？
正如@PinpointTownes暗示的那样，这有点像玩俄罗斯轮盘赌。

MJomaa 于 2017-05-06

👍4

@MJomaa工具在这里会有所帮助，但显然唯一确定的方法是实际运行它。这实际上与在 .NET Standard 支持的框架上运行的 .NET Standard 库没有什么不同。 API 的现有并不能取代测试这些库的需要。这并不是说 netstandard 实现不旨在兼容，但它们是边缘，例如https://github.com/dotnet/standard/blob/cc9f646354fc68a13707a82323d4032b8dbfda52/netstandard/src/ApiCompatBaseline.net461.txt

这些是 NS 2.0 中存在但 .NET Framework 4.6.1 中不存在的 API。

davidfowl 于 2017-05-06

👍1

我对这种变化感到非常紧张，但是在阅读了该主题之后，理论上似乎还不错。我们有 5 个 ASP.NET Core 应用程序，其中 4 个在完整的框架上，但这主要是因为我们比其他任何东西都采取防御措施并采取阻力最小的方式。

我认为 VS 中嵌入的某种工具（例如 .NET Core 可移植性分析器）可以帮助那些在 Twitter/GitHub 上没有更新并且不知道这个扩展甚至存在的开发人员。我想到了“建议扩展”，但我不确定一个人会采取什么行动来触发它。尝试将 net46x 库添加到 ASP.NET Core 2+ 应用程序？

微软无法控制的东西，比如 Telerik、Syncfusion 等的 3rd 方支持也将成为潜在的障碍，具体取决于他们在做什么。

此 GitHub 线程中的消息需要尽快发布到博客文章中，其中包含常见问题解答或其他内容。我觉得我一直在掌握一切，但我仍然不能 100% 确定这是否意味着我们可以引用 net46x 库。我显然也不是唯一对此感到困惑的人。

呼应其他人一直在说的话。我与至少10 位不知道 ASP.NET Core 可以在完整框架上运行的开发人员交谈过。我和@aL3891有同样的经历，尽管开发人员真的很高兴他们可以在完整的框架上运行 ASP.NET Core，而且他们的内部库也能正常工作。再说一遍——关于 .NET Core 2.0 的消息具有绝大多数用例将非常非常重要。关于像 System.DirectoryServices 这样的工作中至少有一个仅限 Windows 的解决方案的文章也很重要。许多 NET 开发人员听到 .NET Core 是跨平台的，并且比 x-plat/perf 更关心他们现有代码的工作时，他们都会耸耸肩。

scottsauber 于 2017-05-06

👍7

伙计们，这是一种垃圾:(
我们构建在 ASP.NET Core 之上，因为可以选择将其与 netfx 一起使用，并且我们构建的东西旨在持续 5-10 年，而不是最长支持 1 年。这就是 ASP.NET 名称在业务中的含义，也是大型、行动缓慢的组织选择它而不是月框架风格的原因。让我继续讨论具体的用例。

我在一个工具组工作，该组构建业务线库和应用程序，供公司内部使用并出售给“企业”客户。在我们的案例中主要是政府组织，但我相信你会从私营部门听到同样的事情。我们有将业务模式编码为通用抽象的内部框架——想想“IDatabaseConnection”、“IEntityProvider”、“IWizardFlow”、“ICodeGenerator”——并在这些可插拔后端之上构建 RAD 前端。

在我们的堆栈中，ASP.NET Core 是一个“插件”——它是一个 HTTP 目标，用作数据存储抽象和托管服务等。它也是一个“前端”——显然有一堆 LOB 应用程序是网站，它是一个很棒的 webapps 新框架。所以我们有双向互操作性要求——引用随机其他组件的 AN-C 代码，以及引用 AN-C 的随机其他代码。

我们完全是 Core CLR 和可移植性的拥护者，我们已经将我们的许多组件移植到目标或多目标网络标准。到目前为止，我们已经有一个托管在 Linux 上的应用程序，并希望有更多的应用程序来。但是，任何东西都不会很快被移植！我们有仍然活跃的、积极开发的代码，它依赖于

NTLM 身份验证（包括围绕令牌和 SPN 的高级方案）
System.Drawing 如上（有趣的皱纹：我们需要旧的图像格式，如 TIFF，新的 OSS 库不支持）
连接到 WCF/SOAP api - 仍然大量存在
Windows 加密 API（包括用于 PKI 令牌的 RSACng、ECDSA 和 CSP）
WPF guis - 我们的客户不会很快切换到 Windows 10，即使他们这样做了，他们也不会想要 Store 应用程序
用于数据导入和导出的 Microsoft Office 互操作（尤其是 access 和 excel）
Visual Studio 可扩展性
第三方插件，如 Oracle ADO.NET 提供程序

Core CLR 永远不会支持其中一些技术。但它们是真正的技术，是新应用程序开发的基础——我们需要一个可以访问这些东西的 .NET 版本。现在我们的位置是可控的：我们将“遗留”（实际上：特定于平台的）依赖项隔离到它们自己的特定于 net461 的组件中。如果特定的业务应用程序需要这些功能，则它们会依赖 netfx，否则不会。我设想了一个新应用程序很少见的未来......但很难想象它永远是 0%。

您在 csproj 和 SDK 上完成了所有这些工作，因为互操作很重要。 ASP.NET Core 是胡萝卜，需要互操作的原因。我认为把它拿走是没有意义的。不，“您可以在一个方向加载您的引用，但它们可能会在运行时失败”不是互操作性。

gulbanana 于 2017-05-06

👍36 ❤4 👎1

@gulbanana您能否描述使用 ASP.NET Core 的系统部分，为什么它们需要与 .NET Framework 处于同一进程中。我很欣赏这个列表（Visual Studio 插件、office 互操作等），但你今天是否在所有这些地方都嵌入了 ASP.NET Core（我没有从上面的描述中得到好的图片）？

另外，在 ASP.NET Core 存在之前您使用的是什么？或者这只是一个从未使用过 ASP.NET 但在 .NET Framework 上押注 ASP.NET Core 5-10 年的新尝试？你看过卡塔纳吗？

davidfowl 于 2017-05-06

好的，这里有一些具体的案例研究。我会提前说，我确信其中很多可以通过在单独的进程中运行特定于桌面的工作来处理，尽管基本上将一堆接口实现转换为 RPC 似乎很麻烦。我们也不能只在核心和桌面 CLR 之间使用远程处理或二进制序列化。

NTLM/AD

出于单点登录的目的，我们的应用程序依赖于浏览器将 Windows 登录凭据传递给 IIS，IIS 将它们传递给 ASP.NET Core 网站。然后，身份验证过程的一部分是查找信息，例如用户是否在特定的 AD 组中。我真的很想听到更多关于“Windows 支持包”的信息，以及它是否打算涵盖这样的内容。

系统绘图

这用于创建缩略图和基本图像编辑（旋转、水印覆盖）的 web 应用程序。许多使用的图像都可以追溯到恐龙时代，所以里面有 TIFF 之类的东西。它们是由政府部门维护的与特定物业清单和土地管理相关的数据。在这种情况下，应用程序最初是 ASP.NET MVC，并通过 MVC 2、4、5 和现在的 Core 进行了升级/重写。

VSIX

这是在 netfx 中嵌入 AN-C 而不是相反的情况。我们有用于代码生成的 Visual Studio 扩展，它们为各种 RAD 场景运行“模板”。其中一些模板是为 Web 开发创建的，并在设计时引用 AN-C 类型（它们是使用预处理器/运行时 T4 创建的）。

加密货币

我认为这个确实必须是进程内的——我们有代码对安全非常敏感的许可方案。从广义上讲，它是根据代码运行的环境解密和验证许可证文件——这是一个用于 web 应用程序后端以及桌面应用程序的通用库。最终，.NET Core 似乎可能会获得足够的加密支持，可以移植这个，但今天还没有。例如，我们今天拥有的一个选项是 Fortinet/ePass2003 PKI 令牌支持，他们的中间件肯定不支持 Core（并且没有这样做的时间表）。

甲骨文ADO.NET

使用带有 Oracle 后端的 Entity Framework 6 不一定是进程内的，但是对于我们的网站来说，为了访问数据库而添加额外的层肯定会很不方便！

WPF 互操作

如今，我们在所有桌面应用程序中都使用 Microsoft.Extensions.Logging - 日志抽象本身需要在进程内，即使实现不是。

gulbanana 于 2017-05-06

👍12

至于我们在 ASP.NET Core 之前使用的是什么——ASP.NET MVC！我们可以回去，但放弃所有的好处将是一种巨大的耻辱。

作为一名架构师，我没有调查“ASP.NET Core 在完整框架上运行”是否会在第一个版本之后持续存在，这是我的错误。老实说，我从来没有想过它不会。我只是没想到早在 2018 年就有可能没有可以加载 Office 文档的受支持版本......

gulbanana 于 2017-05-06

👍31

我不清楚的一件事是 ASP.NET Core 在您提到的每个场景中的使用位置。

NTLM/AD

这是有道理的，我想了解最终映射到的 API。这只是 System.DirectoryServices 吗？那个正在积极开发中（您可以在 corefx 中看到它）。

系统绘图

这是我们正在研究解决的已知差距。我在这里还没有任何答案，我不建议使用 ImageSharp 重写（尽管这是一个选项）。这将需要解决。

VSIX

ASP.NET Core 在哪里？它是否在 Visual Studio 扩展中运行？

加密货币

这个有corefx问题吗？为什么不直接移植？与 .NET Framework 不同，.NET Core 版本与操作系统分离，因此如果认为很重要，这可能会尽快发生。（免责声明：我对加密的了解不够，无法理解做这个跨平台的含义）。

甲骨文ADO.NET

ASP.NET Core 是从哪里来的？您是说 Oracle 提供程序尚未移植到 .NET Core 吗？

如今，我们在所有桌面应用程序中都使用 Microsoft.Extensions.Logging - 日志抽象本身需要在进程内，即使实现不是。

Microsoft.Extensions.* 将保持网络标准，因此您可以在那里得到保障。

davidfowl 于 2017-05-06

👍5

为什么没有公告/讨论？
我喜欢 aspnet/.net 核心团队所做的事情，但我和@jhurdlow 有同样的恐惧。

YuriiPovkh 于 2017-05-06

很高兴听到关于 MEL 在其他方面 -

NTLM

这是我们大多数应用程序中使用的一类。它对 API 的使用非常简单，这些东西有望在理论上被移植（但还没有移植）。
https://gist.github.com/gulbanana/70fe791735ee884169e2eee354a32ad2

VSIX

特定于 asp.net 核心的代码生成模板使用操作/路由系统（IFileProvider 等）来发现控制器和视图等并填充我们的脚手架。我们没有在 Visual Studio 中托管 ASP.NET 虚拟主机，只是对 ASP.NET 应用程序进行内省。

加密货币

我怀疑我们使用的算法会被移植，但还没有移植。如果前提是宣布一项长期计划放弃对 asp.net-core-on-netfx 的支持并讨论何时可能实现，那么这一切看起来都会大不相同！

甲骨文

是的，如果发生 Oracle 端口，这将得到解决（假设它是全功能的等等）。

gulbanana 于 2017-05-06

👍3

另一个用例：
我们的一个应用程序从 Access 应用程序导入旧数据。现在，导入过程在 asp.net 核心网站的服务器上运行。它使用 COM 互操作从 accdb/jet 引擎可再发行组件加载acedao.dll ，将表读取到我们的实体抽象中，然后将它们保存到更现代的 SQL 数据库中。

这是另一种“可能不在过程中，但为什么必须如此”的情况。我们基本上将使用 AN-C 作为 WebAPI 2 网站或其他东西的前端，在这种情况下，我们已经回到了对过去的依赖:(

总的来说，我们的目标是将我们所做的大部分工作转移到 .NET Core。我们希望尽可能多的互操作，同时我们将事情转移过来......

gulbanana 于 2017-05-06

哇！ 😨
你是说 ASP.NET Core 2 将不再以 Full .NET framework 4.x 为目标！！！
1 个月前，我们刚刚使用 ASP.NET Core 1.1 开始了一个项目，我们针对 .NET 4.6，因为我们引用了一些完整的 .NET Lib。我们打算升级到 ASP.NET Core 2。但是我从这篇文章中听到的......😞
看，我们选择 ASP.NET Core 是因为它的优点（DI、合并的 API 和 MVC，……强大），所以，请给我一个改变。

ikourfaln 于 2017-05-07

👍2 😄1

1 个月前，我们刚刚使用 ASP.NET Core 1.1 开始了一个项目，我们针对 .NET 4.6，因为我们引用了一些完整的 .NET Lib

那些图书馆是做什么的？您是否阅读了@shanselman的初始回复https://github.com/aspnet/Home/issues/2022#issuecomment -299536123？可以在 .NET Core 2.0 中引用一些 .NET Framework 库（假设它们位于 API 子集中）。

davidfowl 于 2017-05-07

那些图书馆是做什么的？您是否阅读了@shanselman的初始回复 #2022（评论）？可以在 .NET Core 2.0 中引用一些 .NET Framework 库（假设它们位于 API 子集中）。

@davidfowl是的，我阅读了@shanselman的评论，我们使用公司制造的一些库，其中一些库使用 WCF，所有这些库都是稳定的，它们针对 .NET 3.5，我们无法触及它们。

ikourfaln 于 2017-05-07

这将是一个非常普遍的情况。我很想知道是否已经收集到任何信息（遥测？）关于到目前为止 .NET Core 与 .NET Framework 上有多少 ASP.NET Core 用户。

gulbanana 于 2017-05-07

我个人对此并不情绪化，但有一些观察：

我今天拥有的大多数客户都使用 asp.net core 1.x/full 框架组合，因为他们害怕全神贯注于新东西
从 nuget 包下载数量来看，asp.net core 的采用率并不高。有了这一举措，现在卖得不好的东西就更难卖了。
很高兴您已经确定 LDAP 的东西是一个差距（我想我在过去 10 年中从未见过有人使用这些库，但也许这只是我）。更大的问题将是第 3 方库。这些将是人们不会迁移到 .net 核心的真正原因

这整个情况又是 MS 只是在没有任何提示的情况下做出决定的另一个很好的例子。只是因为有些人关注签到，这里才有这个贴子。

我可能错了，但我认为 .NET Core 现在处于 DNF 的管理之下——所以这些决定不再纯粹是 MS 内部的。

leastprivilege 于 2017-05-07

👍34

LDAP/AD 的东西绝对是我现在需要掌握 net462 的一个原因。我很想完全去 BAM -> NetCore，但这是一个缺点。

我还在我的一个项目中使用 XML-RPC.net。它使用了一些严重的 Reflection.Emit，我不确定 NetCore 2 是否会完全支持它。不过，我必须尝试使用 Portability Analyzer 才能确定。

snickler 于 2017-05-07

我发现整个情况有点令人沮丧，因为像这样影响 .NET 未来的重要决定在最后一刻又一次在没有任何透明度的情况下发生如此迅速和容易。已经投入大量精力来销售现有的 .NET 生态系统以迁移到 ASP.NET Core，其中消息（据我了解）是 .NET Standard 2.0 将专注于兼容性，并将成为弥合与 .NET 差距的版本v4.x 最终产生了一个稳固、稳定的 .NET 平台，生态系统最终可以依赖它。我个人不相信 .NET Core 会在 .NET Standard 2.0 发布之前真正起飞，因为我预计它将成为我们都在等待的“承诺的稳定之地”——现在我不知道什么是“.NET Standard” 2.0" 意味着它到底要涵盖什么以及哪些库计划仅是 .NET Core。

由于没有事先的官方公告、反馈请求、投票或给出理由，这一决定“似乎”是在零社区参与或对现有 .NET 生态系统的影响分析的情况下完成的，并且可能会为许多人分割整个生态系统未来几年。删除 .NET v4.x 支持为许多企业移除了一条平滑的迁移路径，以便能够将其现有代码库迁移到 ASP.NET 的新开发模型。这不会鼓励他们更快地跳转到 .NET Core，它会有效地阻止他们甚至尝试这样做，从而导致将 .NET 生态系统一分为二的巨大碎片。我看不出这最终会与 Python 2/3 有何不同，Python 2/3 受到了近十年来仍未能恢复的碎片化的不可挽回的伤害。

大多数现有的 .NET 代码库都是由“暗物质”.NET 开发人员在幕后开发的棕地，由于 .NET Core 1.1 支持 .NET v4.x，他们中的大多数人都不知道做出这个决定.NET Standard 2.0 的消息传递是提高兼容性的承诺。一旦这个决定的消息和影响最终传到家中，我预计会出现巨大的反弹。许多在其组织内部推销 .NET Core 采用的开发人员会感到被背叛，因为他们实际上一直在迁移到一个死胡同（如果他们出于某种原因无法完全迁移到 .NET Core） ) 在他们成功地说服组织中的利益相关者批准他们当前迁移所需的资源这一重大决定之后，他们将需要面对一个严酷的现实。

大多数组织需要“进行中”迁移他们现有的代码库，他们需要持续部署他们现有的系统，同时“并行”迁移他们想要首先部署到 .NET v4.x 的代码库，然后在一切都稳定下来并解决所有问题之后，他们可以计划从那里完全迁移到 .NET Core。

这一决定也是在多年对 ASP.NET 发生重大变化的背景下做出的，IMO 削弱了对 .NET 是组织可以依赖的稳定平台的信任。我喜欢 .NET Core 的新开发模型，但 IMO 我们最需要的是一个稳定的平台，我们可以依赖它，生态系统的其他部分可以赶上。 .NET Core 仍处于恐怖谷，有不成熟的工具、不兼容的依赖项、运行时问题、过时的文档等等——自从它首次发布的早期以来，我还没有看到 .NET 如此不稳定。

为什么不对 .NET 开发人员想要更多的东西进行投票？即一个坚固、稳定的抛光平台还是一个能够更快地提供新功能的“快速移动”平台？我知道不必担心将功能向后移植到 .NET v4.x 需要更少的努力，但是拥有一个主要专注于提供稳定兼容平台的 ASP.NET Core 版本将是非常宝贵的可以在 .NET v4.x 或 .NET Core 上运行的术语支持。

这艘船已经航行了，还是可以选择保持 ASP.NET Core 2.0 不变？即 .NET Standard 2.0 涵盖了大多数库和抽象，然后在下一个 ASP.NET Core 3.0 版本中宣布下一个平台将仅是 .NET Core？这将允许组织继续前进并采用 ASP.NET Core 2.0，并允许生态系统的其他部分赶上，提供稳定且受良好支持的工具和库，同时与仅 .NET Core 平台/功能开始。

可以在 .NET Core 2.0 中引用一些 .NET Framework 库（假设它们位于 API 子集中）。

这带来了不确定性，很少有人愿意冒着他们的声誉以及系统的健康和稳定性的风险，并在不确定他们的哪些依赖项将能够运行和不能运行时尝试完全迁移到 .NET Core .NET Core，这意味着在可预见的未来会有更多的人继续使用 .NET v4.x。

我真的不知道这最终会如何发展，以及这个决定对整个 .NET 生态系统的真正影响是什么，但事实上，像这样具有广泛影响的重要决定可以在没有任何外部社区参与的情况下发生，这一点令人担忧。

mythz 于 2017-05-07

👍78 ❤14

我希望你们不要那么执着于划分用户群。

在创建库时，我的观点是使其易于使用，尽可能多的人，在尽可能多的地方使用。这是一件令人头疼的事情（在 Newtonsoft.Json 中搜索#if编译器指令，您会得到 1300 多个结果），但“它只是有效”是一个强大的卖点。

JamesNK 于 2017-05-07

👍45

为什么不对 .NET 开发人员想要更多的东西进行投票？即一个坚固、稳定的抛光平台还是一个能够更快地提供新功能的“快速移动”平台？我知道不必担心将功能向后移植到 .NET v4.x 需要更少的努力，但是拥有一个主要专注于提供稳定兼容平台的 ASP.NET Core 版本将是非常宝贵的可以在 .NET v4.x 或 .NET Core 上运行的术语支持。

正版问题，ASP.NET Core 1.x 目前支持.NET Framework 和.NET Core。可以说它是您上面提到的稳定平台，我们在两个运行时都进行了错误修复和支持，但没有获得更多功能。这样就够了吗？

ASP.NET Core 和 .NET Core 是目前快速发展的 .NET 功能丰富的平台。它是一个不与任何操作系统绑定的 .NET 版本，它为我们提供了快速创新和更快发布所需的敏捷性。

这艘船已经航行了，还是可以选择保持 ASP.NET Core 2.0 不变？即 .NET Standard 2.0 涵盖了大多数库和抽象，然后在下一个 ASP.NET Core 3.0 版本中宣布下一个平台将仅是 .NET Core？这将允许组织继续前进并采用 ASP.NET Core 2.0，并允许生态系统的其他部分赶上，提供稳定且受良好支持的工具和库，同时与仅 .NET Core 平台/功能开始。

我们始终乐于接受反馈，并且 ASP.NET Core 2.0 尚未发布。如果 ASP.NET Core 3.0 是放弃 .NET Framework 的版本，那会让事情变得更好吗？如果您查看来自@gulbanana和@ikourfaln的一些反馈，有些技术可能永远不会被移植，因此永远不会在 .NET Core 上运行，这是否意味着几乎永远支持 .NET Framework？一年后我们不会有同样的讨论吗？也许到那时支持 .NET Core 的生态系统或库会更大，因此影响更小？那些永远不会更新的企业库（或者源代码丢失的地方）呢？这些会在一年内改变吗？

davidfowl 于 2017-05-07

👎10 👍5

在创建库时，我的观点是使其易于使用，尽可能多的人，在尽可能多的地方使用。这是一个令人头疼的问题（在 Newtonsoft.Json 中搜索 #if 编译器指令，您会得到 1300 多个结果），但“它只是有效”是一个强大的卖点。

无意冒犯@JamesNK ，但 JSON.NET 是一个 JSON 解析器，并且在大多数情况下是一个单独的包（我知道还有更多）。 ASP.NET Core 有超过 200 个包。

davidfowl 于 2017-05-07

👎41 😕8 👍4

无意冒犯，但我是一个兼职工作的人。您的问题更难，但您拥有成倍增加的资源。

JamesNK 于 2017-05-07

👍57 😄25

在阅读了本文并查看了我们拥有的依赖项之后，我不太相信这是一个好主意。

按照计划，在System.DirectoryServices可用之前，我们不能将我们的任何应用程序移植到netstandard / netcoreapp （ CoreFX issue #2089 here ）。所以虽然我们可以移植到 ASP.NET Core 1.x，但我们不能移植到 2.0。看看这里的应用程序：Opserver、Stack Overflow 本身、我们的内部应用程序……什么都不会准备好，因为此时 2.0 已经准备好了。根据本周的站立会议，像 DirectoryServices 这样的关键功能仍将在 2.x 以后的版本中出现。

所以在 1.0 和 2.0 之间，它从我准备搬到的东西变成了我不能去的东西。所以，是的，我会说它还没有准备好。 ASP.NET 是一种通过 HTTP 公开我需要的位的方法。 ASP.NET 本身并不是我需要的东西。我不只是将 .NET 用于 Web 位，而是将它用于平台……很多人也是如此。该平台还没有为用户需求的各种用例做好准备，因此强迫用户使用该平台会导致痛苦和阻碍。

底线是，如果我们需要 AD auth（平台的很大一部分），我们刚刚被 1.x 线抛弃。这就是我使用我们的应用程序的方向......但如果这是方向，那么在我需要的位在目的地可用之前，在这里付出努力是没有意义的。

如果我们可以说像System.DirectoryServices 、 System.Drawing等重要的事情，以及人们需要的其他最重要的项目将在ASP.NET Core 2.0 中准备好，我的看法就会发生很大变化。如果它们是事后的想法（如当前时间表所示），请继续支持 .NET Framework，直到它们出现。

快速移动很棒。我喜欢它。我现在正在生产中运行 alpha。但是，如果它首先不适用于您的用例，那么这些都不重要。

NickCraver 于 2017-05-08

👍33

我个人正在努力解决的一件事是“稳定平台”与“新功能”的事情。一方面，我们希望平台稳定可靠和兼容，另一方面没有人愿意停留在 1.x 上，因为它没有 2.x 的特性。 ASP.NET Core 2.x 中是否有超级引人注目的功能将人们拉向那个方向，或者仅仅是因为我们拥有比 1.x 中更多的功能（因为它是新的和闪亮的）？

如果是后者，那么那些人在乎稳定吗？如果答案是肯定的，那为什么 ASP.NET Core 1.x 还不够呢？

我不只是将 .NET 用于 Web 位，而是将它用于平台……很多人也是如此。该平台还没有为用户需求的各种用例做好准备，因此强迫用户使用该平台会导致痛苦和阻碍。

同意，但在您看来，这与 ASP.NET Core 2.x 放弃 .NET Framework 支持有何关系？当更多的依赖项上线时，从某种意义上说，它们将在任何地方工作，随着平台的发展，广泛的运行时集将受益。所有版本的 ASP.NET Core 应用程序都将突然能够利用这些功能。

davidfowl 于 2017-05-08

👍4

如果是后者，那么那些人在乎稳定吗？如果答案是肯定的，那为什么 ASP.NET Core 1.x 还不够呢？

每个人总是想要新功能，新功能的可能性，或者至少知道他们可以选择稍后获得更多好东西。当您关闭一个平台并将其置于“稳定”/“维护模式”时，人们会认为它不再受到关注。

clairernovotny 于 2017-05-08

👍7

ASP.NET Core 2.x 中是否有超级引人注目的功能将人们拉向那个方向，或者仅仅是因为我们拥有比 1.x 中更多的功能（因为它是新的和闪亮的）？

支持——这就是我们付出的代价。

如果答案是肯定的，那为什么 ASP.NET Core 1.x 还不够呢？

因为支持在发布后大约一年就结束了（根据上面的 Scott 所说）。到那时我可能几乎无法移植 Stack Overflow。

这与 ASP.NET Core 2.x 放弃 .NET Framework 支持有何关系？

因为我必须拥有的图书馆不在那里。而且我不知道他们什么时候。所以我会被困在 1.x 上，我有一个定时炸弹，直到支持结束。在支持结束之前，我是否有足够的时间从 1.0 移植到 2.x（或 3.x）？可能不是。

大型代码库不能只是停止和移植，它们需要时间，需要分阶段进行。作为中间步骤，将 .NET 4.6.x 移植到 ASP.NET Core 上是可行的。一次进入核心要困难得多，需要更长的时间，并且需要更长寿的分支和更多的痛苦。如果我们不能分阶段做到这一点，老实说，我真的看不到我们会离开现在被放弃的 ASP.NET 5 线。我无法证明它所产生的时间、成本和开发影响是合理的。

我认为许多 OSS 作者也和我一样——这是我们日常工作的延伸。如果我们不使用该平台或对其进行测试，图书馆的情况会更糟，或者不会被创建。而且我们不能用我们今天花费的公司时间来证明维护它们的时间是合理的。我们制作的每个库都来自我们在生产中遇到的需求。生态系统下降用例有很多下游影响，这不是突然的，但仍然会增加。

目前我的观点是这样的：有一个新平台可以运行到 2018 年 7 月左右。在那之后：我什么都不知道，我只希望到那时我需要的东西在netstandard / netcoreapp上可用。并希望我有足够的时间在支持结束之前移植。不过，我并没有希望得到报酬，我得到报酬来为我们公司做出平台决策，而 ASP.NET Core 是一个糟糕的选择（对我们来说），有了这个变化并且没有日期可以工作的版本。

让我提供一个总结：如果没有 .NET Full Framework 支持，ASP.NET Core 在未来 2 年内不会为我们的用例提供支持的平台。

NickCraver 于 2017-05-08

👍75

作为一个简短的版本，它是这样的：

优先级 1：这必须在net461上工作，无论 ifdefs, perf 有什么。
优先级 2。如果您可以在 .NET Core 2.0 上使其速度提高 10 倍，那就太棒了。这是人们选择平台和/或尽可能迁移的一个很好的理由。

这里的关键是，对于长期支持，它仍然必须在整个框架上工作，即使那里速度较慢。

clairernovotny 于 2017-05-08

👍15

优先级 1：这必须在 net461 上工作

如果 .NET Core 与 net461 完全兼容（在合理范围内）；所以为 net461 编写的任何东西都可以在 Core 上运行；那可以吗？

基本上，那时你有一个比 net4x 更稳定的平台，因为你可以并排和自包含（也可以触摸 x-plat）。而net461整机改成4.6.1、4.6.2、4.7等

显然有些事情永远不会奏效；就像部分信任一样——但这无论如何都没有奏效。

benaadams 于 2017-05-08

正版问题，ASP.NET Core 1.x 目前支持.NET Framework 和.NET Core。可以说它是您上面提到的稳定平台，我们在两个运行时都进行了错误修复和支持，但没有获得更多功能。这样就够了吗？

我很想看到 ASP.NET Core 2.0 的 LTS 版本，就像 Ubuntu / Redhat 和他们的 LTS 版本一样，他们支持 5 年以上。它将提供一个可靠的兼容目标，生态系统的其他部分可以有信心承诺采用。

我个人对稳定的 .NET Standard 2.0 比任何未来的 .NET Core 功能更感兴趣，因为我很想回到 .NET 开发，一切都可以再次工作，工具没有损坏，流行的 .NET 开发。 NET 包都提供支持，周围的部署和托管解决方案都经过完善，并且有大量文档、帖子、视频和知识库可用于稳定的 ASP.NET Core，我们可以开始构建解决方案。

一年后我们不会有同样的讨论吗？也许到那时支持 .NET Core 的生态系统或库会更大，因此影响更小？那些永远不会更新的企业库（或者源代码丢失的地方）呢？这些会在一年内改变吗？

在理想的世界中，.NET v4.x 和 .NET Core 在可预见的未来都将支持 ASP.NET Core，而且它只是新的 .NET Core 特性，只能在 .NET Core 包中使用。但是，如果 MS 注定要抛弃 .NET 4.x，那么在正式分道扬镳之前发布 ASP.NET 2.0 LTS 将是下一个最好的选择。根据定义，没有人依赖尚不存在的新功能，因此没有人会被迫升级到仅支持 .NET Core 的 v3.0。

由于只需要支持 1 个平台的自由，您可能会提供新功能，这些新功能会吸引开发人员采用具有持续新功能流的下一个最新和最好的版本，我个人对 ASP.NET 现在所拥有的功能感到满意等等我对一个稳定的版本更感兴趣，它的一切都已经完美了，这样我就可以重新开始工作，专注于开发解决方案，而不是追逐一个永远移动的平台。

mythz 于 2017-05-08

👍8

首先，感谢@davidfowl跳入主题并站起来/提出问题等。当有一个激烈的社区询问大量 Q 时，很容易不介入并避免成为“目标”。因此，感谢您以建设性方式参与其中。 /我向你致敬。

我从这次谈话中看到了两个要点/线索：

请求在 vnext 中支持 .NET 桌面。（这是这里 99% 的回复）
如此重要的决定缺乏社区协商。（这里的 2 或 3 个回复）。

TL;博士;

我们能否对重要的 vnext 更改更加开放。
为社区中有关这些 vnext 更改的一些 RFC 分配一些时间。

@mythz在他（此时）的开场白中很好地说明了这一点，〜最近〜最近的第二条评论：

我发现整个情况有点令人沮丧，因为像这样影响 .NET 未来的重要决定在最后一刻又一次在没有任何透明度的情况下发生如此迅速和容易。

这对我个人来说是真正的打击，我希望来自 MS 的相关人员的一些官方回复/评论，他们打了这些电话 plz。 “我们”在这个社区已经存在了很长时间——熟悉的面孔、熟悉的名字，而且可以说很公平——所有人都遵循着相同的积极目标。我什至会继续说“我们”是一个相当大的大家庭，是个大家庭。

所以我觉得随着 MS 采取的新方向（OSS-all-the-things 等）以及最近 12/18 个月内的一些大型 uber-.NET 线程（阅读：从那些社区讨论经验中学习) ...“我们”都在一起，其中一些真正重要的事情™️将提前公开讨论。

那么——我们能否请您事先公开讨论其中一些重大决定？获得一些积极的社区咨询和讨论？

注意：我确实接受这个项目不是民主的，并且_decisions_ 是由 MS 制定的。没有问题。我不是在批评那个。我说的是在那之前的步骤。此外，我不是要求为 RFC 等提供 _everything_。只是奇怪的主要票项 - 就像这个线程已经开始的那样。

PureKrome 于 2017-05-08

👍44 ❤11

但是，如果 MS 注定要抛弃 .NET 4.x，那么在正式分道扬镳之前发布 ASP.NET 2.0 LTS 将是下一个最好的选择。根据定义，没有人依赖尚不存在的新功能，因此没有人会被迫升级到仅支持 .NET Core 的 v3.0。

我不明白。没有人依赖 ASP.NET 2.0 中的功能，因为它们在发行版中不存在。那么 ASP.NET Core 1.x 不是那个版本吗？它在完整的框架、core 1.0 和 core 2.0 上运行，可以作为 ASP.NET Core 2.x 的垫脚石吗？

benaadams 于 2017-05-08

👍1

@onovotny

每个人总是想要新功能，新功能的可能性，或者至少知道他们可以选择稍后获得更多好东西。当您关闭一个平台并将其置于“稳定”/“维护模式”时，人们会认为它不再受到关注。

是的，但是当 .NET Framework 是与 OS 组件相关的大稳定支持时，很难保证相同的质量水平。正如@terrajobst所说，有些东西肯定会在某个时候被移植，但其他东西需要弄清楚。事实是，ASP.NET Core 在 .NET Core 上运行得最好，因为我们有能力一次性修改整个堆栈。到目前为止，这 2 个运行时之间存在很大的性能差异，并且由于 .NET Framework 支持，我们还没有依赖新的 API。随着我们的前进，我们将添加新的 API，这些 API 在某些时候可能会出现在 .NET Framework 上，也可能不会出现，我们不希望以最稳定和最慢的运行时 (.NET Framework) 的速度进行更新。

@尼克克拉弗

因为支持在发布后大约一年就结束了（根据上面的 Scott 所说）。到那时我可能几乎无法移植 Stack Overflow。

我不确定这是否完全准确。当 2.0 可用时，仍将支持 1.1。那么你所说的“支持”是什么？您的意思是付费支持还是我们会在出现问题时解决问题？

因为我必须拥有的图书馆不在那里。而且我不知道他们什么时候。所以我会被困在 1.x 上，我有一个定时炸弹，直到支持结束。在支持结束之前，我是否有足够的时间从 1.0 移植到 2.x（或 3.x）？可能不是。

就像我说的那样，无论 .NET Core 版本如何，这些库都会亮起来。我认为你的意思是你想使用最新版本的 ASP.NET Core（不管是什么），并且你希望它在 .NET Framework 上得到支持，直到 .NET Core 上有足够的库以便移植对于您的特定场景很容易。

大型代码库不能只是停止和移植，它们需要时间，需要分阶段进行。作为中间步骤，将 .NET 4.6.x 移植到 ASP.NET Core 上是可行的。一次进入核心要困难得多，需要更长的时间，并且需要更长寿的分支和更多的痛苦。如果我们不能分阶段做到这一点，老实说，我真的看不到我们会离开现在被放弃的 ASP.NET 5 线。我无法证明它所产生的时间、成本和开发影响是合理的。

ASP.NET Core revving 版本对此有何影响？如果我们在 3.0 中放弃了对 .NET Framework 的支持（正如人们似乎在此线程中所逃避的那样），无论如何，您不会陷入同样的死胡同吗？您将 ASP.NET Core 2.0 应用程序移植到框架上运行一年，当 3.0 发布时，您将无法升级。无论如何，您都可以使用在 .NET Framework 上运行的 ASP.NET Core 1.1.x 来执行此操作，即使在 ASP.NET Core 2.0 发布时也受支持。

目前我的观点是：有一个新平台可以运行到 2018 年 7 月左右。在那之后：我什么都不知道，我只希望到那时我需要的东西在 netstandard/netcoreapp 上可用。并希望我有足够的时间在支持结束之前移植。不过，我并没有希望得到报酬，我得到报酬来为我们公司做出平台决策，而 ASP.NET Core 是一个糟糕的选择（对我们来说），有了这个变化并且没有日期可以工作的版本。

所以一年对每个人来说都足够了吗？这不是我从这个线程中得到的感觉。

davidfowl 于 2017-05-08

👍4

优先级 1：这必须在 net461 上工作，无论 ifdefs 是什么，perf 都有。
优先级 2。如果您可以在 .NET Core 2.0 上使其速度提高 10 倍，那就太棒了。这是人们选择平台和/或尽可能迁移的一个很好的理由。

这里的关键是，对于长期支持，它仍然必须在整个框架上工作，即使那里速度较慢。

.NET Framework 能像今天这样工作的唯一原因是我们有意支持它。它不是免费的，也不是“只是在核心上更快”，我们必须有意识地设计系统，以便使其能够在 .NET Framework 上运行。即使您还没有看到，一旦我们决定（并且我们已经决定）依赖于 .NET Framework 中尚不存在的 API，两者之间的功能差距将会扩大。我们可以按照@PinpointTownes所说的去做，并在出现这些功能差距时开始抛出NotSupportedException ，但 IMO 的体验非常糟糕。

davidfowl 于 2017-05-08

👍5 ❤1

我们花费了大量的开发预算将我们的 ASP.net MVC5 应用程序移植到 ASP.net 核心完整框架，以使其与 Azure Service Fabric 一起工作。整个项目历时数月，其中有数周时间专门用于移植我们的 Web 应用程序（坦率地说，与笨拙的 VS2015 工具搏斗）。

唯一可行的原因是因为支持完整的框架，因为我们目前在 ASP.net 核心上运行 SignalR（ @davidfowl气馁）。据我所知，Asp.net Core 仍然不支持 SignalR？

然后我们花了一周左右的时间迁移到新的 VS2017 工具。美好的。

_请注意，到目前为止，产品根本没有任何改进，只是调整代码形状以适应微软的平台和工具要求。_

现在你告诉我，在 12 个月内，我将不得不执行更多毫无特色的开发工作，但不能保证我什至能够做到，这取决于一堆手挥手，应该能够做到？不用了，谢谢。

首先，让人们在 ASP.net 核心完整框架中使用的所有微软品牌都只在 ASP.net 核心上工作。其次，找出还有什么（如果有的话）会阻止生态系统按照需要采用 ASP.net 核心。然后，并且只有在那时，才放弃对 Netfx 的支持，正如我们正在讨论的那样。

jahmai 于 2017-05-08

👍7

我们可以按照@PinpointTownes所说的去做，并在出现这些功能差距时开始抛出 NotSupportedException，但 IMO 这是一个非常糟糕的体验。

这不是我所说的：在进行交叉编译时， ifdefs绝对应该是排除特定平台上不可用的 API 的首选选项，但如果出于某种原因，您绝对必须公开此 API 签名合同，那么您可以使用NotSupportedException 。

kevinchalet 于 2017-05-08

我不明白。也没有人依赖 ASP.NET 2.0 中的功能

我预计大多数开发人员在承诺迁移到 ASP.NET Core 之前，都在等待其依赖项支持的稳定且高度兼容的 .NET Standard 2.0。他们现在不想采用 .NET Core 1.1，因为他们知道它已经停产，而且 MS 没有为任何旧的 DNX/.NET Core 版本提供长期支持的良好历史。如果生态系统的其他部分可以安全地采用高度兼容的稳定 LTS 版本，企业应该拥有在其上运行系统所需的一切，并且他们不会觉得有必要升级到 .NET Core vNext，因为他们将拥有一切需要 v2.0，到时候计划从 ASP.NET Core 2.0/.NET v4.6 迁移到未来的仅 .NET Core 版本会容易得多。

mythz 于 2017-05-08

👍6

@mythz

我个人对稳定的 .NET Standard 2.0 比任何未来的 .NET Core 功能更感兴趣，因为我很想回到 .NET 开发，一切都可以再次工作，工具没有损坏，流行的 .NET 开发。 NET 包都提供支持，周围的部署和托管解决方案都经过完善，并且有大量文档、帖子、视频和知识库可用于稳定的 ASP.NET Core，我们可以开始构建解决方案。

同意那里的一切，但我不明白这个决定如何影响你所说的任何事情。我想要所有这些相同的东西👍。

由于只需要支持 1 个平台的自由，您可能会提供新功能，这些新功能会吸引开发人员采用具有持续新功能流的下一个最新和最好的版本，我个人对 ASP.NET 现在所拥有的功能感到满意等等我对一个稳定的版本更感兴趣，它的一切都已经完美了，这样我就可以重新开始工作，专注于开发解决方案，而不是追逐一个永远移动的平台。

对了，那不是 ASP.NET Core 1.x 吗？如果在 1.x 上扩展支持还不够吗？我们可以确保 ASP.NET Core 1. 即 netstandard 1.x 在 .NET Core 2.0 上运行（它已经这样做了）并支持它一年左右。

davidfowl 于 2017-05-08

👍5

这不是我所说的：在进行交叉编译时，ifdefs 绝对应该是排除特定平台上不可用的 API 的首选选项，但是如果出于某种原因您需要在公共合约中具有此 API 签名，那么您可以使用 NotSupportedException。

我什至不是在谈论公开公共 API。我说的是我们需要调用的 API，这些 API 在 netstandard 中不存在。 #ifdefs 在这里没有帮助。我们会随着差距的增加而投掷。

davidfowl 于 2017-05-08

@davidfowl完全有效的问题 - 答案：

您的意思是付费支持还是我们会在出现问题时解决问题？

问题的主动修复 - 1.x 是否会收到我们破坏的所有内容的修复，或者在某些情况下我们会被告知升级修复？（注意：在我们的库（如 DirectoryServices）出现之前，我们无法进行升级……即使我们可以，它也远不及免费甚至便宜，至少可能需要几个月的时间）。我们很大，我们很快，我们会在框架中找到突破口。多年来，我们为每个主要和次要版本提供服务。支持对我们至关重要。

我想你说的是你想使用最新版本的 ASP.NET Core

不，我想要一个可行的版本和一条前进的道路。对于 1.x，我们只有前半部分。在这个问题之前，第二个是假设的。

ASP.NET Core revving 版本对此有何影响？

因为如果您放弃对完整框架的支持，我们将被迫进行重大更改以保持支持。

如果我们在 3.0 中放弃了对 .NET Framework 的支持（正如人们似乎在此线程中所逃避的那样），无论如何，您不会陷入同样的死胡同吗？

可能是？关键是在进行潜水之前在用例中具有同等地位。这是我的事业，当对方可能不支持我们的时候，我不能告诉我们公司跳槽。那只是我的不负责任。如果我们的用例在 2.x 时间范围内得到支持，那么就有一条清晰的前进道路，押注 ASP.NET Core 会更安全。

所以一年对每个人来说都足够了吗？

时间的绝对长度并不重要——它需要是用例兼容性+时间（IMO）。如果我们的用例在今天有效（例如 AD auth），那么 2 年就足够了，是的。但目前情况并非如此，因此同意从现在开始的任意时间点是可以的，充其量是为时过早。

它不是免费的，也不是“只是在核心上更快”，我们必须有意识地设计系统，以便使其能够在 .NET Framework 上运行。即使您还没有看到，一旦我们决定（并且我们已经决定）依赖于 .NET Framework 中尚不存在的 API，两者之间的功能差距将会扩大。

那么没有冒犯，但为什么不直接说出来并关闭问题呢？这句话似乎没有什么可讨论的了，我们的时间最好花在其他地方。如果不是这样，请澄清一下？

主要问题是我们不能将我们的工作负载移植到今天的netstandard ，或者按照目前的提议，在发布时移植。如果我们已经拥有的东西不起作用，我们为什么要关心新功能？团队一直在谈论性能（这真的很棒），但我不能使用快速运行的东西真的没关系。

作为架构/平台负责人，我必须决定我们要下什么赌注。目前，这是一个糟糕的选择。当版本 1 支持您但版本 2 不支持但希望有朝一日会支持您时，用其他人的时间和金钱进行的赌博真的很糟糕。至少对我们来说，我们选择 .NET 来获得功能、生态系统和支持。目前，在新词中，我们已经从所有 3 个变为 1 个。生态系统还不存在（API 表面、库），支持比我们习惯的要短得多，没有任何保证的升级路径和一个未知的时间来这样做。

NickCraver 于 2017-05-08

👍15

@jahmai

唯一可行的原因是因为支持完整的框架，因为我们目前在 ASP.net 核心上运行 SignalR（ @davidfowl气馁）。据我所知，Asp.net Core 仍然不支持 SignalR？

ASP.NET Core 甚至不支持 SignalR 2（尽管人们已经破解了它以使其工作）。 SignalR 仍在开发中，甚至不会与 ASP.NET Core 2.0 一起推出，它会在以后推出。

现在你告诉我，在 12 个月内，我将不得不执行更多毫无特色的开发工作，但不能保证我什至能够做到，这取决于一堆手挥手，应该能够做到？不用了，谢谢。

ASP.NET Core 2.0 中是否有您需要的功能？或者您只是推测最终您需要升级到下一个 ASP.NET Core，而此时 .NET Framework 将无法运行？

首先，让人们在 ASP.net 核心完整框架中使用的所有微软品牌都只在 ASP.net 核心上工作。其次，找出还有什么（如果有的话）会阻止生态系统按照需要采用 ASP.net 核心。然后，并且只有在那时，才放弃对 Netfx 的支持，正如我们正在讨论的那样。

作为 netstandard 2.0 的一部分，已经完成了大量工作来识别要恢复的重要 API，以便以 .NET Framework 为目标的库在很大程度上与它兼容。当然，有些领域像 WCF、WPF 等那样不起作用，但它会有所帮助，因为我们做了一些研究，大约 60% 的库 API 与 netstandard 2.0 兼容（如果我在那个数字上错了，请纠正我@terrajobst）并且可能只适用于 .NET Core 2.0。

davidfowl 于 2017-05-08

对了，那不是 ASP.NET Core 1.x 吗？如果在 1.x 上扩展支持还不够吗？

我预计 .NET Standard 2.0 将成为与 .NET 4.x 兼容的稳定平台，因此 LTS 支持将围绕这一点更有意义。没有人期望 1.1/.NET v4.x 会在发布中期 EOL，因此在发布最新版本时宣布 LTS 将是尊重的，而不是在发布之前取消对 .NET 4.x 的支持，不 -一个人在回顾这样的旧版本时进行 LTS。

我知道我们在单独的*.Core包中维护我们的 .NET Core 包，因此当我们合并到主要 NuGet 包时，我们可以保持遵循最新 .NET Core 版本的单独发布节奏我们致力于发布一个我们将正式支持的稳定版本，因此我们需要非常有信心，我们有一个可以在可预见的未来支持的版本，我期望 .NET Standard 2.0，而不是当前的 .NET Standard 1.1/1.3/1.6 混合。我记得曾经有一段时间会有一个 1.7/8 的止损版本，它与 2.0 不兼容，打破了 .NET 标准版本控制的期望，这不是稳定平台的信号。

我一直焦急地期待 .NET Standard 2.0 注定会提供备受追捧的高度兼容的表面积和急需的稳定性。

mythz 于 2017-05-08

👍2

ASP.NET Core 甚至不支持 SignalR 2（尽管人们已经破解了它以使其工作）。 SignalR 仍在开发中，甚至不会与 ASP.NET Core 2.0 一起推出，它会在以后推出。

不知道你是如何打算这样说的，但我觉得它只会加剧我的担忧。

ASP.NET Core 2.0 中是否有您需要的功能？或者您只是推测最终您需要升级到下一个 ASP.NET Core，而此时 .NET Framework 将无法运行？

出于某种原因，我想在某个时候移至 netstandard2。为此，我需要将我的网络应用程序移动到 asp.net core 2，对吗？

作为 netstandard 2.0 的一部分，已经完成了大量工作来识别要恢复的重要 API，以便以 .NET Framework 为目标的库在很大程度上与它兼容。 <...>

当然，我喜欢 netstandard 所做的事情，但是如果 netstandard 缺少某些东西，您可以解决，因为您可以在需要它的应用程序中定位完整框架。我们现在有一些纯 netstandard 1.3 库（我们的源代码）共享：Xamarin.iOS、Xamarin.Android、net46、Asp.net core 1.1 - 因为我们可以使用特定框架目标库（包括 net46 东西）来补充 netstandard 中缺少的功能在我们的 asp.net 核心网络应用程序中。

我们拥有这些 netstandard 库的唯一原因是因为我们需要移植我们庞大的 Web 应用程序（正如我之前提到的）。我_喜欢_不必为其他平台扩展我们的平台特定代码库，而是继续向上移动 netstandard 链。我真的不想被困在 netstandard 1.3 上，因为没有办法转移到 asp.net core 2。

jahmai 于 2017-05-08

问题的主动修复 - 1.x 是否会收到我们破坏的所有内容的修复，或者在某些情况下我们会被告知升级修复？（注意：在我们的库（如 DirectoryServices）出现之前，我们无法进行升级……即使我们可以，它也远不及免费甚至便宜，至少可能需要几个月的时间）。我们很大，我们很快，我们会在框架中找到突破口。多年来，我们为每个主要和次要版本提供服务。支持对我们至关重要。

我认为支持没有问题。我实际上不认为这将是一个大问题，如果它让人们对下注更有信心，那么也许值得将对 1.x 的支持扩展到更长的时间范围。

不，我想要一个可行的版本和一条前进的道路。对于 1.x，我们只有前半部分。在这个问题之前，第二个是假设的。

这只是意味着您需要保留在 1.x 上，直到您的所有依赖项都被移植，不是吗？

@NickCraver你所有的抱怨都是在谈论 .NET Core 而不是 ASP.NET Core 上缺少的东西。在 .NET Core 1.x 和 ASP.NET Core 1.x 中，这两个实体一起发布，但完全解耦。除了对 v1 支持某些东西而 v2 不支持它的有效担忧之外，我还没有听说过想要使用 ASP.NET Core 2.0 的单一原因。我认为如果有另一个原因您无法仅移植到 .NET Core（可能在完整框架上开发 ASP.NET Core 期间，您采用了一些新的依赖项，那么我们将在一年内进行完全相同的讨论）永远不会被移植作为例子）。

那么没有冒犯，但为什么不直接说出来并关闭问题呢？这句话似乎没有什么可讨论的了，我们的时间最好花在其他地方。如果不是这样，请澄清一下？

我在这里回答和回复，因为我试图弄清楚为什么我们需要支持 .NET Framework，如果需要，支持多长时间。关于这些时间框架，我仍然对这个线程有不同的看法。还有一种普遍的恐惧，我可以理解“降级到 ASP.NET Core 1.x”，但就 2.x 中需要的特定功能而言，没有什么具体的。

我喜欢将 .NET Core 和 ASP.NET Core 结合起来的主要优点之一是它解决了一些版本控制和命名问题。很多人甚至不知道 ASP.NET Core 是在 .NET Framework 上运行的（它甚至会使堆栈的新手感到困惑）。也就是说，我们有很多客户有很多不同的需求，我们听取他们的反馈。

davidfowl 于 2017-05-08

👍7

@mythz

我一直焦急地期待 .NET Standard 2.0 注定会提供备受追捧的高度兼容的表面积和急需的稳定性。

当然可以，但就像我说的，1.x 中的 ASP.NET Core、.NET Core 和 .NET Standard 是完全解耦的。您可以在任何支持它的 .NET Core 版本上使用任何 .NET Standard 库。因此，如果 .NET Core 2.0 是新的 LTS，我们仍然可以声明它支持 ASP.NET Core 1.x。

@jahmai

出于某种原因，我想在某个时候移至 netstandard2。为此，我需要将我的网络应用程序移动到 asp.net core 2，对吗？

不，这是不对的。您可以随时迁移到 netstandard 2，而无需将 Web 应用迁移到 ASP.NET Core 2.0。

我们拥有这些 netstandard 库的唯一原因是我们需要移植我们庞大的 Web 应用程序（正如我之前提到的）。我希望不必为其他平台扩展我们平台特定的代码库，而是继续向上移动 netstandard 链。我真的不想被困在 netstandard 1.3 上，因为没有办法转移到 asp.net core 2。

您不必拘泥于 netstandard 1.3。 2件事是无关的。

davidfowl 于 2017-05-08

👍2 ❤1

当版本 1 支持您但版本 2 不支持但_希望有一天会_时，这真是一场糟糕的赌博....

我认为这是问题的症结所在。我们有评论指出，_some_ 的差距（ DirectoryService等）是已知的并将得到解决。我们需要更具体的东西。

我对针对 .NET Core 的 ASP.NET Core 没有意见，如果路线图明确说明我们可以预期何时解决这些差距（以及哪些差距）（再次假设有足够的时间移植之前），我们会错过 2.0 船1.X 变得不受支持）。

从目前的情况来看，我们在 WCF 中被阻止的问题自 2015 年 5 月以来一直停滞不前，可能永远不会得到解决.. 让我们陷入困境。

ctolkien 于 2017-05-08

👍1

@davidfowl

不，这是不对的。您可以随时迁移到 netstandard 2，而无需将 Web 应用迁移到 ASP.NET Core 2.0。

优秀。在这种情况下，只要 Microsoft 确保支持 1.x（各种错误修复和操作支持），直到它为客户提供适当的 2.x 迁移路径（例如 SignalR），那么我很乐意等待时间，直到我们需要asp.net核心2。

jahmai 于 2017-05-08

👍4

这只是意味着您需要保留在 1.x 上，直到您的所有依赖项都被移植，不是吗？

正确，但这必须是一个已知的时间范围。我们没有日期，到目前为止我们被告知的唯一一件事是“不在 2.0 中”......所以这不好。例如， System.DirectoryServices自 2015 年中以来一直被请求，但仍然缺失，但经常被重复为用户最想要的（其次是System.Drawing ）。说我们将 .NET Standard 2.0 的 API 对等性提高到 60%，但缺少用户最需要的部分，肯定会发出关于什么是重要的混合信号。

您的所有抱怨都在谈论 .NET Core 而不是 ASP.NET Core 上缺少的东西。

这是不正确的。我需要在受支持的平台上运行所需的位（例如 AD 身份验证）。缺少的是后者的支持。对 1.x 的支持当然是我主要关心的问题。我们没有支持的前进道路或任何时间表来说明我们何时可以期待。

我想我们会在一年内进行完全相同的讨论

我认为情况并非如此。问题是我们今天不能移植。 API 不存在。只要我们甚至没有能够移植的单一时间点，关于未来的讨论就有点没有意义了。我希望 ASP.NET Core 中的 .NET 完整框架支持一旦出现奇偶校验并且大多数用户可以迁移，就会被弃用。而且我希望该版本能够为人们提供较长的支持时间。

如果 DirectoryServices、Drawing 等在 2.x 中出现，那就太棒了。该版本应该支持 .NET Framework，并且是 LTS 版本。并且 3.x 应该放弃完整的框架支持。

我喜欢将 .NET Core 和 ASP.NET Core 结合起来的主要优点之一是它解决了一些版本控制和命名问题。很多人甚至不知道 ASP.NET Core 是在 .NET Framework 上运行的（它甚至会使堆栈的新手感到困惑）。也就是说，我们有很多客户有很多不同的需求，我们听取他们的反馈。

很公平，但所有的疯狂都是次要的“它甚至有效吗？”。目前，这是一个坚定的不。 ASP.NET 和 .NET Core/Standard/whatever 可能是微软内部的 2 套东西（我完全明白），但对于开发人员来说，它仍然是 1 个平台。 ASP.NET 端需要 API 对许多人有用，但它们还没有。这一举措进一步减少了可用的 API。 ASP.NET 团队可能会得到他们想要的，但这是以我们需要的为代价的。

NickCraver 于 2017-05-08

👍16

@ctolkien @NickCraver

我认为这是问题的症结所在。我们已经评论说一些差距（DirectoryService 等）是已知的，并将得到解决。我们需要更具体的东西。

正确，但这必须是一个已知的时间范围。我们没有日期，到目前为止我们被告知的唯一一件事是“不在 2.0 中”......所以这不好。例如，System.DirectoryServices 自 2015 年中期以来一直被请求，但仍然缺失，但经常被重复为用户最想要的（其次是 System.Drawing）。

不过，这些差距与 .NET Core 本身有关，我可以理解不知道这些依赖项何时可用的焦虑，这就是为什么帮助我们确定这些依赖项的优先级的原因。好消息是 netstandard 2.0 和 netcoreapp2.0 奠定了小组工作的基础，使其他库更容易移植。我希望在我们发布 2.0 之后，通过在我们非常兼容的基础上移植大量代码来建立其他依赖项会容易得多。

davidfowl 于 2017-05-08

👍3 ❤1

CSOM会在 netcore 2 中运行吗？这对我们来说将是一个巨大的障碍，也是我从未听说过的一个领域。

smbecker 于 2017-05-08

👍1

@davidfowl我也真诚地希望也是如此，但我不会把我们公司押在这上面。在此之前而不是之后放弃支持，我强烈不同意。我认为在针对许多消费者的关键 API 到位之后，在 3.x 时间范围内发生的这种情况是完全有效的。在他们准备好之前这样做只会停止我们的采用。

我正在采用 1.0，假设2.x（或任何积极开发/修复的东西）将支持完整的框架，直到那些关键的 API 准备好（我是认真的 - 你知道我已经在库中投入了多少工作）。但在这一点上，我不能在 Stack 这样做......这是一个糟糕的假设。在任何端口的未来都如此不确定的情况下，我不能凭良心告诉我们的团队使用 .NET Core。我真的希望我能，但现在不值得冒险和痛苦。

NickCraver 于 2017-05-08

👍12

@尼克克拉弗

我希望 ASP.NET Core 中的 .NET 完整框架支持一旦出现奇偶校验并且大多数用户可以迁移，就会被弃用。而且我希望该版本能够为人们提供较长的支持时间。

这里“大多数用户”的衡量标准是什么？在我们放弃支持之前需要覆盖哪些依赖项列表？您的列表与此列表中的其他用户不同。我还希望有些人会说永远或直到 .NET Core 达到 .NET Framework 平价（这是不现实的）。我仍然认为 ASP.NET Core 1.x 足以达到这个目的，我们应该考虑将对此的支持扩展到上述时间。

这是不正确的。我需要在受支持的平台上运行所需的位（例如 AD 身份验证）。缺少的是后者的支持。对 1.x 的支持当然是我主要关心的问题。我们没有支持的前进道路或任何时间表来说明我们何时可以期待。

这种情况下缺少什么 ASP.NET 组件？当您说 1.x 与 2.x 时，如果您提及 ASP.NET Core 与 .NET Core，将会很有用。

如果 DirectoryServices、Drawing 等在 2.x 中出现，那就太棒了。该版本应该支持 .NET Framework，并且是 LTS 版本。并且 3.x 应该放弃完整的框架支持。

我之前提到过，您需要哪些 ASP.NET Core 功能而 ASP.NET Core 1.x 还不够？

ASP.NET 和 .NET Core/Standard/whatever 可能是微软内部的 2 套东西（我完全明白），但对于开发人员来说，它仍然是 1 个平台

同意，但我们需要澄清有关此讨论的 FUD，以便我们能够正确评估影响。 ASP.NET Core 1.x 面向 .NET Standard 1.x (1.0 - 1.6) 和 .NET Framework 4.5.1。这意味着它可以在任何支持这些版本的 netstandard 和 .NET Framework 的平台上运行。这意味着 ASP.NET Core 1.x 将在 .NET Core 2.0 上运行。

davidfowl 于 2017-05-08

@smbecker

CSOM 会在 netcore 2 中运行吗？这对我们来说将是一个巨大的障碍，也是我从未听说过的一个领域。

我不知道那是什么。这是https://msdn.microsoft.com/en-us/library/ff798388.aspx 吗？如果是这样，则没有做任何工作来明确支持它。它可能只是基于 .NET Core 2.0 中的 .NET Framework 兼容性而工作，但我的猜测是它永远不会被移植到 .NET Core（仅基于我 5 分钟的研究），但我可能错了。

davidfowl 于 2017-05-08

这里“大多数用户”的衡量标准是什么？在我们放弃支持之前需要覆盖哪些依赖项列表？您的列表与此列表中的其他用户不同。我还希望有些人会说永远或直到 .NET Core 达到 .NET Framework 平价（这是不现实的）。我仍然认为 ASP.NET Core 1.x 足以达到这个目的，我们应该考虑将对此的支持扩展到上述时间。

让我们从最缺少的 API 开始 - 这些是导致大多数人阻塞的原因。对我们来说，这是排名第一的 DiretoryServices。如果它甚至不存在，这对社区来说是一个非常糟糕的信号。我同意列表是不同的，但如果我们甚至不包括第 1名...

这种情况下缺少什么 ASP.NET 组件？当您说 1.x 与 2.x 时，如果您提及 ASP.NET Core 与 .NET Core，将会很有用。

我之前提到过，您需要哪些 ASP.NET Core 功能而 ASP.NET Core 1.x 还不够？

我的意思是支持支持完整框架的最新 ASP.NET Core（以及我需要的库）。我希望那是 2.x，因为我们需要模块、剃须刀页面等。我们已经使用了很多 2.x 功能。但听起来我们目前唯一的选择是 1.x。我们无法从 ASP.NET 5 跳转到 ASP.NET Core，也无法从包含所有工作库的完整框架跳转到netcoreapp一步。太多了。成本太高了。这太冒险了。现在我们不确定我们是否可以在支持窗口内进行这种昂贵、冒险的举动。这是一个糟糕的情况 - 糟糕到最好不要移动（就像今天的情况一样）。我认为这真的很不幸。

NickCraver 于 2017-05-08

👍3

这种情况下缺少什么 ASP.NET 组件？当您说 1.x 与 2.x 时，如果您提及 ASP.NET Core 与 .NET Core，将会很有用。

除非有办法通过一些 Microsoft.Authentication.* NuGet 包来处理 AD 身份验证/查询，否则这是一件大事。我目前在同一条船上，但由于我在 .NET 462 之上运行 .NET Core 1.1，我将能够实现这一目标。除此之外，我如何能够通过支持的方式查询任何 AD 组、元数据？我在 corefx repo 中看到有很多关于System.DirectoryServices的工作，所以我至少对此感到高兴。
System.Data.Common.DbDataAdapter / SqlClient.SqlDataAdapter 。目前，我只能在完整的 .NET Framework 之上的 .NET Core 上运行时访问它。我想这更方便，因为我仍然可以使用DbDataReader / SqlDataReader 。

基本上我需要知道，在使用 ASP.NET Core 2.x 时，将有一些支持的方式来处理 AD 身份验证，而不需要完整的 .NET Framework。

snickler 于 2017-05-08

今天我一直在思考这个问题，我发现我的担忧与这里的大多数人不同（并不是说这些担忧不那么重要，如果不是更重要的话）。

我仍然对在netstandard上使用 ASP.NET Core 包的用例感到困惑。直到这个问题，我一直假设（可能是错误的） netstandard是库的实际目标。换句话说，图书馆作者的预期行为将是针对netstandard ，除非有必要且令人信服的理由不这样做。这不仅确保了与 Framework 的兼容性，还确保了与 Xamarin 和 UWP 等其他平台的兼容性。 .NET Standard 2.0 上的工作似乎通过尝试将各种运行时的 API 表面区域统一到一个常见的不需要考虑它的目标中来支持这一点。

对我来说，这种变化标志着一些不同的东西。诚然，归根结底，ASP.NET Core 只是一个库，也许它确实有“必要且令人信服的理由”不支持常见的netstandard表面积。但它也是最引人注目的 Microsoft 开发的 .NET 库之一，并且通过说“我们想要最新和最好的，因此我们将停止支持netstandard ”它向所有其他库开发人员（或在至少对我有影响）也许他们应该停止努力支持netstandard并开始瞄准核心运行时。当微软甚至不那么关心它时，为什么还要为所有这些兼容性问题烦恼呢？ .NET Core 4 生命周期。也许这是最好的——它肯定不同于我认为我们使用多个运行时和一个基本统一的 API 表面区域的地方。

当考虑到 ASP.NET Core 包含许多直接在 ASP.NET 上下文之外有用的库时，这种担忧会变得更深。假设那些曾经打算单独使用可能是错误的，但松开它们将是一个可怕的耻辱。想要使用它们的库作者将不得不决定将自己的目标也切换到 .NET Core，或者继续使用netstandard并放弃对它们的访问。我怀疑很多人会选择前者，进一步分裂对替代平台的库支持。至少如果我理解了这里的评论，即针对支持库的不同平台太难了。

最后，我有点（虽然少一点）关心这里的评论，即一旦有可能新的 API 将被添加到 Core 以与 ASP.NET 一起进行修订。特别是那些新的 API 可能永远不会进入netstandard或 .NET Framework。我当然明白，如果放弃或放松遗留和兼容性问题，可能会有一些令人兴奋的事情可以完成。但坦率地说，我的印象是 ASP.NET Core 团队经常在外面冲锋陷阵。这不一定是一件坏事，但它也导致了一些更广泛的决定，不得不撤回。我不禁想知道，随着时间的推移，这以及随后核心运行时的快速发展是否会导致运行时集大大破裂（同样，不仅仅是 Windows/Framework 会被抛在后面——还有还有 Xamarin、Mono、UWP 等）。

这整个线程使我重新定位了我对 .NET Core 的未来的理解，而不是netstandard 。也许我太极端了，在接下来的几周里这种情况会有所缓和，或者这甚至是预期的立场，这一切都是最好的——不管怎样，我目前很想出去为我自己的目标定位 .NET Core东西，只关注我在这里读到的所有内容。

daveaglick 于 2017-05-08

👍30

@尼克克拉弗

我的意思是支持支持完整框架的最新 ASP.NET Core（以及我需要的库）。我希望那是 2.x，因为我们需要模块、剃须刀页面等。我们已经使用了很多 2.x 功能。

现在是 1.1.1（2.0 中没有模块），Razor Pages 是一个很好的，另一个是 SignalR。这些是我认为其中最痛苦的两件事。

我们无法从 ASP.NET 5 跳转到 ASP.NET Core，也无法从包含所有工作库的完整框架跳转到 netcoreapp。太多了。成本太高了。这太冒险了。现在我们不确定我们是否可以在支持窗口内进行这种昂贵、冒险的举动。这是一个糟糕的情况 - 糟糕到最好不要移动（就像今天的情况一样）。我认为这真的很不幸。

是吗？假设您的依赖项已被移植，那么从 ASP.NET Core 1.x 到 2.x 或 3.x 的迁移将是微不足道的。如果您总体上打算迁移到 ASP.NET Core，迁移到 1.1 是一个很好的第一步，并且您不会节省任何避免它的工作。

davidfowl 于 2017-05-08

@snickler

基本上我需要知道，在使用 ASP.NET Core 2.x 时，将有一些支持的方式来处理 AD 身份验证，而不需要完整的 .NET Framework。

在 .NET Core 支持 System.DirectoryServices 之前，您是否有理由不能在 .NET Framework 上使用 ASP.NET Core 1.x？

davidfowl 于 2017-05-08

在 .NET Core 支持 System.DirectoryServices 之前，您是否有理由不能在 .NET Framework 上使用 ASP.NET Core 1.x？

这就是我目前正在做的事情。我只是期待，如果我不需要的话，我不必担心 .NET Framework。目前，它限制我使用我的 Windows 机器，因为 Mono 中不存在System.DirectoryServices.AccountManagement命名空间。在同样的方面，在 Windows 的限制之外是否会有System.DirectoryServices.AccountManagement可用？这一点迫使我在本地调试 MVC 项目和 Xamarin.iOS 应用程序时在机器之间切换。

snickler 于 2017-05-08

如果您总体上打算迁移到 ASP.NET Core，迁移到 1.1 是一个很好的第一步，并且您不会节省任何避免它的工作。

我完全同意，如果我们在升级到另一个有效的平台之前知道支持。目前，我们不知道 .NET Core 世界中什么时候可以使用必要的位，所以现在设置一个时间上限并且不知道这些位以后什么时候会出现，这是我押注的一个承诺。这才是核心问题。如果我们有一个支持的、重叠的版本允许移植，那么我会准备好并乐于投资。如果在 API 出现之前就放弃了支持，那么我们将在信仰上跨越一个鸿沟，跑道数量未知。

我一直在引用 DirectoryServices，因为我知道这对今天的netcoreapp2.0不起作用。当然，我们还会发现其他一些事情是同舟共济的。我们需要 ASP.NET Core + 完整的框架 + 在某些平台上几年的支持。在 1.x 中，我们没有获得太多收益，实际上我们获得的收益很少。性能并不是一个令人敬畏的论点，因为我们已经在大约 18 毫秒内渲染页面，而且它与传输时间相形见绌。然而，2.0 提供了相当多的好项目。 Razor 页面和插件的前景使其非常吸引人。如此之多，以至于是合理的。

现在，唯一需要支持的版本（1.1.x 具有更长的支持，是我在阅读此线程后所期望的）不值得迁移。基本上要花很多时间和精力才能达到我们今天的水平。 2.x 至少提供了一些不错的改进和我们想要利用的位。它们有助于证明搬家成本的合理性。

NickCraver 于 2017-05-08

👍8

性能并不是一个很棒的论点，因为我们已经在大约 18 毫秒内渲染了页面

在一次次要的 OT 咆哮中，我想知道您如何能够在 ~ 18ms @NickCraver内呈现页面。棒极了

snickler 于 2017-05-08

@daveaglick

我仍然坚持在 netstandard 上使用 ASP.NET Core 包的用例。在这个问题之前，我一直认为（也许是错误的）netstandard 是库的实际目标。换句话说，库作者的预期行为将是针对 netstandard，除非有必要且令人信服的理由不这样做。这不仅确保了与 Framework 的兼容性，还确保了与 Xamarin 和 UWP 等其他平台的兼容性。 .NET Standard 2.0 上的工作似乎通过尝试将各种运行时的 API 表面区域统一到一个常见的不需要考虑它的目标中来支持这一点。

这里没有任何改变。事实上，我们想要在其他平台上运行的一堆库仍然是 netstandard。如果你重新阅读上面的一些内容：

Microsoft.Extensions.*（日志记录、DI、配置、文件提供程序等）
实体框架
SignalR 客户端（它们需要在 .NET Framework、Xamarin、UWP 等上运行）。

.NET Standard 是编写可随处运行的库的事实上的方式。图书馆作者应尽可能以 netstandard 为目标，以获得最广泛的平台范围。图书馆作者必须决定他们是否想要接触。这就是 JSON.NET 等库支持 netstandard1.x 和 .NET framework 2.0 的原因。正如上面提到的@JamesNK ，他们加倍努力使事情“正常工作”。

ASP.NET Core 在某些地方远离 netstandard 更像是一种声明，即这些 API 不适用于 UWP 应用程序，我们当然不会在那里测试它们（例如）。它还试图巩固 .NET Core 和 ASP.NET Core 是一起版本的单一产品（因为它的名称中有 Core）。在 ASP.NET Core 1.x 支持 .NET Core 和 .NET Framework 的情况下，该消息有点模糊，它会导致很多人（尤其是新开发人员）感到困惑，我们这样做是为了缓解库差距问题。

当考虑到 ASP.NET Core 包含许多直接在 ASP.NET 上下文之外有用的库时，这种担忧会变得更深。假设那些曾经打算单独使用可能是错误的，但松开它们将是一个可怕的耻辱。想要使用它们的库作者将不得不决定将他们自己的目标也切换到 .NET Core，或者保持在 netstandard 上并放松对它们的访问。我怀疑很多人会选择前者，进一步分裂对替代平台的库支持。至少如果我理解了这里的评论，即针对支持库的不同平台太难了。

我猜那些仍然是网络标准。哪些不是？

我不禁想知道，随着时间的推移，这以及随后核心运行时的快速发展是否会导致运行时集大大破裂（同样，不仅仅是 Windows/Framework 会被抛在后面——还有还有 Xamarin、Mono、UWP 等）。

我认为 netstandard会发展，但 .NET Framework 将永远是最后一个获得新 API 的（Xamarin 和 Mono 的添加速度非常快）。

davidfowl 于 2017-05-08

👍3

@snickler

这就是我目前正在做的事情。我只是期待，如果我不需要的话，我不必担心 .NET Framework。目前，它将我限制在我的 Windows 机器上，因为 Mono 中不存在 System.DirectoryServices.AccountManagement 命名空间。在同样的方面，是否有 System.DirectoryServices.AccountManagement 在 Windows 的约束之外可用？这一点迫使我在本地调试 MVC 项目和 Xamarin.iOS 应用程序时在机器之间切换。

确保在 dotnet/corefx 上提交类似的问题。假设您的依赖项将被移植（除非它非常流行）是错误的做法。

davidfowl 于 2017-05-08

👍2

@davidfowl问题：我想使用 ASP.NET Core 2.0 归档 -> 新项目并针对 AD 进行身份验证。这可能吗？我简直无法想象微软平台如果没有这样做的能力。

NickCraver 于 2017-05-08

👍2

同意那里的一切，但我不明白这个决定如何影响你所说的任何事情。我想要所有同样的东西

通过放弃对 .NET v4.x 的支持，它将扼杀一个流行的迁移路径，并进一步分裂 .NET 生态系统，并阻止许多开发人员和组织采用它，这将减少更广泛的社区知识库和对 ASP 的投资。 NET Core，因为许多 .NET 开发人员将需要无限期地支持他们现有的 ASP.NET v4.x 代码库（他们获得报酬才能全职工作）。

.NET Core 的市场份额越小，库维护者支持它的优先级就越低，如果他们为一个不再能够考虑迁移到 ASP.NET Core 的组织工作，有些人可能永远不会支持它。这反过来又会影响其他依赖于他们的包的人，依此类推。这些都是增加采用 ASP.NET Core 负担的副作用，因为没有稳定的平台，没有长期的支持保证，现在扼杀了流行的迁移路径。

我相信这里的每个人都希望 .NET 生态系统蓬勃发展，但似乎我们与 MS 团队在如何最好地实现它的问题上存在分歧，因为我坚信在已知数量、高度兼容之前放弃 .NET v4.x，可以使用稳定的 LTS 版本是一个错误，它将在未来几年产生不利影响。

mythz 于 2017-05-08

❤10

@davidfowl谢谢 - 你的评论很有帮助。作为此更改的一部分，我已经（显然是错误地）收集到大多数/所有支持库都将退出netstandard 。我使用了很多，并且知道其他人也这样做，所以听到他们不是很受欢迎的消息。

daveaglick 于 2017-05-08

👍1

@NickCraver您今天对 AD 使用哪种身份验证？ OpenIdConnect、WsFed、NTLM 还是其他？

Tratcher 于 2017-05-08

@Tratcher AD auth，通过 DirectoryServices（我们需要查询组成员资格等 - 标准位）

NickCraver 于 2017-05-08

👍1

@mythz我认为这是合理的，我认为延长 ASP.NET Core 1.x 的支持生命周期足以涵盖大多数情况。

davidfowl 于 2017-05-08

❤4 👍4

我明白为什么你必须在某个时候做出这个决定，但我也认为这还为时过早，最高兴的是：

ASP.NET Core 2.x 是 LTS 并且最后支持完整框架（当然，因为我们已经在预览中，所以你不会走得太远），今年晚些时候 SignalR 也支持它，因此它是实现跳跃的目标框架从 ASP.NET 到 ASP.NET Core
3.x 放弃对完整框架的支持，并在迁移顶级依赖项时发布

在我看来，仅仅扩展对 ASP.NET Core 1.1 的支持是不够的，因为该平台还不够成熟/被采用，不足以成为许多 ASP.NET 迁移的目标（在我的情况下 SignalR 是阻碍者）。

rohatsu 于 2017-05-08

👍6 😄1

只是为了 lulz，我尝试使用 EntityFramework 6 - 我已经看到在我从事过的 ASP.NET Core 1.0 应用程序中大量使用它 - 以及最新的 preview2 .NET Core nightly builds。你猜怎么了...

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp2.0</TargetFramework>
    <NetStandardImplicitPackageVersion>2.0.0-*</NetStandardImplicitPackageVersion>
    <RuntimeFrameworkVersion>2.0.0-preview2-002093-00</RuntimeFrameworkVersion>
    <PackageTargetFallback>net45;net461</PackageTargetFallback>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="EntityFramework" Version="6.1.3" />
    <PackageReference Include="System.Configuration.ConfigurationManager" Version="4.4.0-*" />
  </ItemGroup>

</Project>

不要再假装为完整框架设计和编译的程序集将在 .NET Core 上完美运行：琐碎案例（阅读 hello world 应用程序）可能会起作用，但在许多情况下，您最终会被缺少 API 或非功能性 API 阻止.

绝对可怕的是，您只会意识到它在运行时不起作用。在某些情况下，它甚至根本不明显。例如，.NET Core 的SqlClient不支持环境事务登记，也不支持使用TransactionScope的分布式事务：即使您找到了使 EF 6 工作的方法，您的TransactionScope s根本不会有效，您的数据库调用也不会使用您需要的隔离级别。

kevinchalet 于 2017-05-08

👍11 😕10

就我对这一举动的担忧而言，我觉得有必要在这里加两分钱。我们有一个桌面应用程序，它主要是 Windows 窗体，其中一些是在 WPF 中开发的较新区域。在这个应用程序中已经有超过 15 年的努力，并且需要数年才能完全摆脱 WinForms。我希望不是这样，但它是。我们一直在努力在代码库中构建更多的模块化，以便我们可以在更新的 Web 界面和现有的 WinForms 应用程序中使用业务和数据访问层。我打算很快为我们的新 Web 应用程序迁移到 ASP.NET Core，但正如我刚才所说，我将需要消耗我们现有的大部分针对 .NET v4.6.x 的代码库。我确定我们正在使用 System.Drawing 和 System.Security.Cryptography。我们还以上述方式大量使用 TransactionScope。

我一直非常期待获得 ASP.NET Core 的一些好处，例如能够将 Web 应用程序的区域封装到单独的程序集中，而无需依赖 MEF 将它们组合在一起。还有许多其他原因，但正是这一点使它变得非常好。但是，如果我将我们的应用程序转换到 ASP.NET Core，在可预见的将来我可能会停留在 1.x 上，因为我们必须使用 WinForms 维护后端代码的可移植性。我一直主要关注 Web 产品，所以我不能告诉你我们在哪里连接到 WMI 等东西，以及它是否会影响可移植性问题，但我知道我们在我们的代码库中。我们现在正处于一个非常有趣的阶段，我要做的最后一件事是将我们功能的所有 Web 版本开发到 ASP.NET MVC 5 上，并积累一堆需要移植的新遗留代码未来的努力。

我敢肯定，即使/当我们不再使用 WinForms 时，我们也会有很多用途让我们远离 .NET Standard。我们是微软的合作伙伴，我们通过多种方式直接与微软合作开发我们的产品，所以我不想详细介绍我们在这里所做的事情，但我很乐意与@进行更私密的讨论@davidfowl ，如果您需要更多关于我们正在做的事情的详细信息。我也将参加 MS Build，如果您在场，我可以在那里与你们见面并交谈。

我认为你没有考虑过使用你的堆栈的公司面临这些挑战。但是，完全免责声明：我确实打算运行前面提到的可移植性分析器，看看我们确实卡在哪里，因为需要在我们的代码库中维护这种可移植性。我很乐意为您提供未通过该检查的任何 .NET Framework API 的列表。

millman82 于 2017-05-08

哇哈哈。不知道该笑还是该哭……

这是 ApiPort 分析工具为我的 23 行 EF 6 应用程序生成的报告，该应用程序不起作用：

kevinchalet 于 2017-05-08

👍4 😕3

交叉编译是必须与客户和产品需求平衡的开销。这就是为什么我们希望获得此反馈，以便在我们继续发展 ASP.NET Core 向前发展时，我们可以更具体地定义我们的客户和我们的环境。

在打开此问题之前，是否有反馈流程？

brockallen 于 2017-05-08

👍4

我们都在谈论时间框架和对 1.1 的支持，但 ASP.NET Core 将完全放弃完整框架的事实让我感到非常惊讶。

我的理解是，核心框架是一个跨平台的游戏，一个新的框架，它由不与 Windows 耦合的完整框架的一个子集组成。 2.0 版本是我们一直在等待的版本，我们可以从那里获得大部分 API。

ASP.NET Core 是这个新框架的狗粮，一个新的 Web 框架，它依赖于框架 API 的如此小的表面积，它可以在任何地方运行。

我期待一旦核心框架与完整框架非常接近，所有新的 API 都将被添加到 netstandard 中，并最终进入这两个框架。我们都将开始瞄准 netstandard，一切都将是彩虹和独角兽。

现在要找到 ASP.NET 甚至不会 dogfood netstandard 而是要使用特定于框架的 eh ：/

jkells 于 2017-05-08

👍5

@rohatsu

在我看来，仅仅扩展对 ASP.NET Core 1.1 的支持是不够的，因为该平台还不够成熟/被采用，不足以成为许多 ASP.NET 迁移的目标（在我的情况下 SignalR 是阻碍者）。

如果 SignalR 在 ASP.NET Core 1.x 上工作会怎样？您需要的平台还有哪些不成熟的地方？

davidfowl 于 2017-05-08

@millman82感谢分享。听起来您确实会在 .NET Framework 支持被放弃一段时间之前停留在该版本上。因此，我们保持 2.x 兼容而 3.x 将放弃它的一些建议可能甚至对您不起作用。为什么不继续使用 ASP.NET Core 1.x？你的港口需要什么？或者它只是与@NickCraver相同的问题（2.x 不支持它会让你对下注感到紧张）。

davidfowl 于 2017-05-08

@jkells

我期待一旦核心框架与完整框架非常接近，所有新的 API 都将被添加到 netstandard 中，并最终进入这两个框架。我们都将开始瞄准 netstandard，一切都将是彩虹和独角兽。

这并不牵强，只是缺少时间部分。最终将使其成为每个按自己的时间表发货的所有框架。

现在要找到 ASP.NET 甚至不会 dogfood netstandard 而是要使用特定于框架的 eh ：/

正如在这个线程中多次提到的那样，它的一部分仍然以 netstandard 为目标。

davidfowl 于 2017-05-08

为什么不继续使用 ASP.NET Core 1.x？

你不能 - 从 2.0 下降（假设 2.0 是下一个 LTS）起 1 年它就不再支持了。

ctolkien 于 2017-05-08

@davidfowl这绝对是其中的很大一部分。我们还在我们当前的 Web 应用程序中使用 OData 和 SignalR，并且需要在 ASP.NET Core 中才能迁移。但是，我不希望发生的一件事是当对 ASP.NET Core 1.x 的支持被删除并且我们正在使用的当前不支持的框架部分没有迁移路径时陷入困境。我预计 ASP.NET Core 将大量替换 ASP.NET。它可能在路上的某个地方，但它即将到来。知道我现在不想在 ASP.NET MVC 5 中重写我们的 UI（我们现在有一些东西，但很容易移动，因为它很小），直到几年后在 ASP.NET Core 中再次重写它一旦 ASP.NET 的生命终结到来。

如果在 ASP.NET Core 1.x 的 EOL 确实到达时，如果我们现在以 Core 1.x 为目标，如果在过渡期间扩展它，那么如果该迁移路径不存在，我们可能会让自己陷入困境。我们可能可以使用微服务来解决其中的一些问题，但是，这当然有其自身的问题。

millman82 于 2017-05-08

@ctolkien

你不能 - 从 2.0 下降（假设 2.0 是下一个 LTS）起 1 年它就不再支持了。

假设当 2.0 下降时它并没有失去支持。这还不够吗？

davidfowl 于 2017-05-08

但是，我不希望发生的一件事是当对 ASP.NET Core 1.x 的支持被删除并且我们正在使用的当前不支持的框架部分没有迁移路径时陷入困境

在该句子中将 1.x 替换为 2.x。您是否认为在一年内您的所有依赖项都会被移植？

davidfowl 于 2017-05-08

在该句子中将 1.x 替换为 2.x。您是否认为在一年内您的所有依赖项都会被移植？

然而，一点也不，我希望当他们不再能够以 .NET Full 为目标时。我理解您为什么要推动这一点，但我认为您不能指望公司采用将失去支持且无法过渡到新版本的东西，因为缺少的依赖项尚未被移植。

millman82 于 2017-05-08

👍4

我不认为您可以期望公司采用将失去支持而无法过渡到新版本的东西，因为缺少的依赖项尚未被移植。

为什么会失去支持？在我假设的世界中，我们将在 .NET Framework 上支持 ASP.NET Core 1.x 的时间更长。

davidfowl 于 2017-05-08

为什么会失去支持？在我假设的世界中，我们将在 .NET Framework 上支持 ASP.NET Core 1.x 的时间更长。

我的问题是还要多久？此外，团队是否足够大，可以将 SignalR 和 OData 等必要的依赖项引入 ASP.NET Core 1.x 并保持支持，直到所有缺少的依赖项实际上都被移植？似乎它反驳了之前提出的关于为什么现在要放弃 .NET 完全支持的论点。老实的问题...

millman82 于 2017-05-08

我的问题是还要多久？此外，团队是否足够大，可以将 SignalR 和 OData 等必要的依赖项引入 ASP.NET Core 1.x 并保持支持，直到所有缺少的依赖项实际上都被移植？似乎它反驳了早先提出的关于为什么现在要放弃 .NET 完全支持的论点。老实的问题...

我会抛出一个随机数，3年。 ASP.NET 团队不拥有 Odata 集成，odata 团队拥有，所以我无法为他们回答。至于 SignalR，我认为可以针对 ASP.NET Core 1.x。

我看到的问题是，每个人都有一组不同的“缺少的依赖项”，这使得我们无法推断何时“可以”放弃对每个人的 .NET Framework 支持。也有可能其中一些依赖项可能永远不会被移植（如 CSOM）。
当然，在 1.x 列车上，您将获得错误修复和次要功能，但大部分工作仍将在 ASP.NET Core 的最新专业中进行。

此外，这些都不会阻止您将 .NET Core 2.0 或 .NET Standard 2.0 与 ASP.NET Core 1.x 一起使用。我只是想确保每个人都知道这一点，因为这个线程不断地将 ASP.NET Core 与 .NET Core 混为一谈（这是我们只想针对 .NET Core 的原因之一）。

davidfowl 于 2017-05-08

我看到的问题是，每个人都有一组不同的“缺少的依赖项”，这使得我们无法推断何时“可以”放弃对每个人的 .NET Framework 支持。

参与生态系统以找出列表是什么（不，这个问题不是这样做的地方）。如果它是 Microsoft 拥有的依赖项，请移植它。如果不是，请与所有者联系，告知他们计划并协助提供迁移指南（如果他们不做任何事情，这不是 Microsoft 的错）。在经过这个过程的时间里，支持 ASP.net core 1.x。在不惹恼很多人的情况下，我看不到任何其他方法可以实现您的目标。这是一件大事，需要高度关注和关注才能做好。

jahmai 于 2017-05-08

👍6

就个人而言，我认为 .NET Framework 与 .NET Standard 与 .NET Core 之间存在更多混淆。当我看到我可以针对 .NET Framework 时，我从未说过，“但这是 ASP.NET Core，所以我为什么可以使用 .NET Framework”。对于您的大多数客户群来说，上述区别更加令人困惑。我喜欢 ASP.NET Core 所做的一切。也喜欢 .NET 关于平台独立性的方向。我只是认为混淆的领域被错误地陈述了。我想说你的大多数用户群将有一些不可移植的代码，因为它正在做的事情的性质和它在框架内的目标 API。

我的偏好是在 .NET Core 和 .NET Standard 和 .NET Framework 中实现 API 对等。此外，找出人们应该努力瞄准的目标。正如我相信之前所说的那样，也许以稍微不同的方式，.NET Standard 感觉就像一个创可贴。最终，我希望 .NET Core 成为唯一的“框架”选项，而当这种情况发生时，.NET Framework 和 .NET Standard 就会被淘汰。我自己，以及我认为自公告发布以来的大多数人都希望能够继续从您在 ASP.NET Core 方面所做的工作中受益，而不必自由地执行他们的代码被移除。

我认为那些被认为是例外的情况，比如我依赖于 WMI 之类的东西的情况并不像团队想象的那么例外。同样，我会进行研究，看看缺少什么（尽管之前给出不正确的可移植性结果的帖子让我有点担心准确性），我很乐意在更私人的媒体上向你报告。

归根结底，我们对此充满热情，因为我们想使用它。

millman82 于 2017-05-08

👍1

就个人而言，我认为 .NET Framework 与 .NET Standard 与 .NET Core 之间存在更多混淆。当我看到我可以针对 .NET Framework 时，我从未说过，“但这是 ASP.NET Core，所以我为什么可以使用 .NET Framework”。对于您的大多数客户群来说，上述区别更加令人困惑。我喜欢 ASP.NET Core 所做的一切。也喜欢 .NET 关于平台独立性的方向。我只是认为混淆的领域被错误地陈述了。我想说你的大多数用户群将有一些不可移植的代码，因为它正在做的事情的性质和它在框架内的目标 API。

我们有很多客户，我们有新的开发人员，他们一生中从未见过 .NET。我们需要迎合每个人，因为这就是我们作为 Microsoft 努力做的事情。运行在 .NET Framework 上的人知道、喜爱并理解它的工作原理，因此确保您了解 ASP.NET Core 运行在 .NET Framework 上，但作为接近该平台的新开发人员，我希望永远不要提及这一点，因为与go或node之类的东西（此时它们的遗产几乎为 0）。

我的偏好是在 .NET Core 和 .NET Standard 和 .NET Framework 中实现 API 对等。此外，找出人们应该努力瞄准的目标。正如我相信之前所说的那样，也许以稍微不同的方式，.NET Standard 感觉就像一个创可贴。最终，我希望 .NET Core 成为唯一的“框架”选项，而当这种情况发生时，.NET Framework 和 .NET Standard 就会被淘汰。我自己，以及我认为自公告发布以来的大多数人都希望能够继续从您在 ASP.NET Core 方面所做的工作中受益，而不必自由地执行他们的代码被移除。

这些事情都是并行发生的。在将“一切”从 .NET Framework 移植到 .NET Core 之前，ASP.NET Core 不会停止处理功能。 ASP.NET 将继续创新并利用 .NET Core 上可用的 API，因为我们作为同一个盒子的一部分提供。

davidfowl 于 2017-05-08

👍1

我在这个线程上看到了一些趋势的想法：

我希望你永远支持 .NET Framework。
在移植我的应用程序所需的依赖项之前，我希望您支持 .NET Framework。
我只需要 1 年的时间，这足以让我放弃对 .NET Framework 的支持（ASP.NET Core 3.x）。

还有一个事实是我们没有发布公告（这是我们的错），但即将发布（我保证，我责怪周末）。

我也不知道对于这里的大多数人来说 API 奇偶校验是什么样的，我猜对不同的人来说它是不同的。 .NET Framework 是一项与 Windows 相关联的可靠、可靠的企业技术，已有 15 年以上的历史。
.NET Core 是为编写现代轻量级跨平台微服务而设计的，并且逐渐发展为更具兼容性，因此移植库更容易。也就是说，我不知道在兼容性方面接近 .NET Framework 意味着什么，或者这是否是一个目标（最初不是）。在某些时候，您将无法在 .NET Framework 之上使用 ASP.NET Core，并且会有一些无法重写且与 .NET Core 不兼容的依赖项。应用程序在设计时需要考虑到 ASP.NET Core（在不久的将来）。

davidfowl 于 2017-05-08

就我从事的项目而言，对 1.1 的更长支持期将是一个不错的缓解措施。我们不太可能在 1 年内放弃 netfx 依赖项，但更有可能的是您作为稻草人建议的 +3 年。不过，如果能在 2.0 级别首先发布所有内容，那就太好了——这就是所有内容都应该变得更容易移植的地方！我只代表一个组织发言，但“2.0 将是 LTS 版本；3.0 将放弃 netfx”对我们来说基本上是照常营业，而不是 FUD 的原因。

我还想附和@PureKrome所说的关于欣赏这种参与的说法，这是一次非常丰富的讨论。

gulbanana 于 2017-05-08

关于奇偶校验 - 我之前假设 .net core 永远不会达到 .net framework 级别的兼容性，但这很好，因为asp .net core 将继续支持这两者。

我认为作为一个社区，我们基本上使用 .net core 是为了使用 asp.net core，而不是为了它自己的优点。就像您说的那样，它们是一种产品，我认为核心 clr 是该产品的可选部分，如果选择的话，它具有优点和缺点。

gulbanana 于 2017-05-08

👍5

睡了一晚后——

我个人认为放弃旧的 .net 框架并为现代运行时编写最好的 Web 框架是一个好主意。

但是您知道这绝对是有风险的，并且您可能会在此过程中失去一些客户（我希望不会 - 但我做了很多咨询工作 - 而且 .NET Core 对于许多公司来说现在遥不可及 - 希望 2.0改变）。

..是的 - 围绕这个的交流（像往常一样）是你可以改进的（这句话对德国人来说最礼貌的版本）；）

leastprivilege 于 2017-05-08

👍12 ❤5

+1

xiexingen 于 2017-05-08

我个人认为放弃旧的 .net 框架并为现代运行时编写最好的 Web 框架是一个好主意。

我强烈同意。我希望这将是一个渐进的变化，例如 Kestrel 首先放弃对 perf 的支持（剩余基于 http.sys 的托管），然后 mvc/* 紧随其后的是 API 和功能改进，同时开始对 netstandard2.0 进行移植/兼容性测试工作。

dasMulli 于 2017-05-08

👍4

优秀。在这种情况下，只要 Microsoft 确保支持 1.x（各种错误修复和>操作支持），直到它为客户提供适当的 2.x 迁移路径（例如 SignalR），那么我>愿意等待我的时间直到我们需要 asp.net core 2。

+1

只能移植到 .NET Core（也许在完整框架上开发 ASP.NET Core 的过程中，您采用了一些永远不会移植的新依赖项作为示例）。

完全同意。
现在我认为这是一个很好的决定。我认为在理想情况下，我们需要超过 1 年的支持，我不知道可能需要 2-3 年，以及有关将移植什么的信息，以增强社区的信心。
没有 .net 461 支持。

YuriiPovkh 于 2017-05-08

@dasMulli

我强烈同意。我希望这将是一个渐进的变化，例如 Kestrel 首先放弃对 perf 的支持（剩余基于 http.sys 的托管），然后 mvc/* 紧随其后的是 API 和功能改进，同时开始对 netstandard2.0 进行移植/兼容性测试工作。

我们甚至没有在 .NET Framework 上运行性能测试……无论如何，移植测试和对 .NET Core 和 .NET Standard 的改进都会发生，IMO 与是否放弃对 .NET Framework 的支持无关。如果有的话，它会让我们专注于这些场景，因为它是唯一的目标。

davidfowl 于 2017-05-08

@gulbanana

不过，如果能在 2.0 级别首先发布所有内容，那就太好了——这就是所有内容都应该变得更容易移植的地方！我只代表一个组织发言，但“2.0 将是 LTS 版本；3.0 将放弃 netfx”对我们来说基本上是照常营业，而不是 FUD 的原因。

为什么需要 ASP.NET Core 2.0（忘记 .NET Standard 和 .NET Core 2.0）？

davidfowl 于 2017-05-08

我们并不特别需要 asp.net core 2.0 中的功能。我非常希望拥有 2.0 波附带的更简单的构建过程和互操作。如果在 netcoreapp2.0 上运行，asp.net core 1.1 是否能够使用 netstandard2.0 库？这是否会被视为“标准”和受支持的场景，而不是没有人测试或关注的场景？

gulbanana 于 2017-05-08

👍1

基本上，如果 1.1 成为 LTS，我担心问题会在 18 个月后以“好吧，你可以使用 2.0 apis”来解决。

gulbanana 于 2017-05-08

我们并不特别需要 asp.net core 2.0 中的功能。我非常希望拥有 2.0 波附带的更简单的构建过程和互操作。如果在 netcoreapp2.0 上运行，asp.net core 1.1 是否能够使用 netstandard2.0 库？这是否会被视为“标准”和受支持的场景，而不是没有人测试或关注的场景？

这当然行得通。正如我一直在说的那样，今天这三件事完全脱钩了。下面是一个在 .NET Core 2.0 上运行 ASP.NET Core 1.1 的示例项目，它使用已移植到 .NET Standard 2.0 包的 System.Configuration API 版本：

https://github.com/davidfowl/AspNetCore1OnNetCore2

davidfowl 于 2017-05-08

👍6

如果 .NET Core 和 .NET Framework 之间有一个自动互操作层（不是当前可以在运行时抛出异常，也不是自制的内部 WebAPI 调用），我会更乐意接受这一点——某种包装器（“WowNET”？）这将迫使我们将依赖 4.6 的代码保留在单独的 .dll 中，但允许以性能为代价运行遗留代码（在 LOB 应用程序的情况下，这不是主要问题）。你认为这在技术上可行吗？

我还想知道这种变化是否意味着整个框架本身即将结束生命，并且一旦大多数 API 迁移到 .NET Standard，除了成为遗留组件之外，它不会发挥任何其他重要作用。

rohatsu 于 2017-05-08

👍1

基本上，如果 1.1 成为 LTS，我担心问题会在 18 个月后以“好吧，你可以使用 2.0 apis”来解决。

这总是一个问题。答案总是“视情况而定”。错误修复会被相应地权衡，大功能可能会更频繁地落入该桶中。

davidfowl 于 2017-05-08

@rohatsu

如果 .NET Core 和 .NET Framework 之间有一个自动互操作层（不是当前可以在运行时抛出异常，也不是自制的内部 WebAPI 调用），我会更乐意接受这一点——某种包装器（“WowNET”？）这将迫使我们将依赖于 4.6 的代码保留在单独的 .dll 中，但允许以性能为代价运行遗留代码（在 LOB 应用程序的情况下，这不是主要问题）。你认为这在技术上可行吗？

有点像https://docs.microsoft.com/en-us/windows/uwp/porting/desktop-to-uwp-root但对于 .NET Core 和 .NET Framework。当我们 ASP.NET 支持 Helios 时，我们做了非常相似的事情，Helios 是一个 .NET Framework 垫片，用于在 IIS 中提升 coreclr。尽管它是 COM 和通过 string[] args 将结构传递给 Main 方法的混合，但使它工作的黑客非常难看。不过在技术上都是可行的。我不确定您期望什么样的保真度，因为它们不是相同的运行时并且您不能来回传递对象。您还将在同一进程中运行 2 个 GC，2 个更多的 dll，我不确定您在 proc 之外做某事会获得什么。

我还想知道这种变化是否意味着整个框架本身即将结束生命，并且一旦大多数 API 迁移到 .NET Standard，除了成为遗留组件之外，它不会发挥任何其他重要作用。

远非。 .NET Framework 以 Windows 的速度发展和发布，因为它是一个 Windows 组件。我们刚刚发布了 .NET Framework 4.7 (https://blogs.msdn.microsoft.com/dotnet/2017/04/05/announcing-the-net-framework-4-7/) 以及一系列新功能。事实是 .NET Core 可以并且将会更快地发布，因为它不依赖于任何其他东西，因此 API、运行时特性等将首先出现在那里。这并不意味着事情最终不会向 .NET Standard 和 .NET Framework 发展。只是需要更长的时间才能到达那里。 .NET Framework 就地更新这一事实是我们在移植更改时如此小心的原因。当更新自动推送到十亿台机器时，任何更改都可能破坏任何应用程序😉。使用 .NET Core，该框架是并行的，因此应用程序需要选择加入较新的版本以获得较新的功能或修复。那里有更多的自由。

davidfowl 于 2017-05-08

只是为了权衡我们目前在 ASP.NET Core 1.x 中的 net4x 库，这在 2.0 中不起作用：EntityFramework 6。EFCore 只是缺少许多我们使用的缺失功能（例如拦截/生命周期挂钩）。所以我们在 EF6 上停留了一段时间。

根据@PinpointTownes的帖子，EF6 不适用于当前（开发中）版本的 ASP.NET Core 2.x。

nphmuller 于 2017-05-08

@nphmuller那么您将继续使用 ASP.NET Core 1.x 直到移动更多依赖项（我不知道您需要 EF Core 提供多少东西以及状态是什么）。

davidfowl 于 2017-05-08

@davidfowl当然，如果 ASP.NET Core 1.x 的支持窗口在此期间没有通过。
主要特点是拦截（生命周期钩子）。我们可以更轻松地解决其他缺失的功能。拦截在他们的积压中，但与发布无关。我的直觉告诉我，它暂时不会实施。

nphmuller 于 2017-05-08

@gulbanana ：我认为作为一个社区，我们基本上使用 .net 核心是为了使用 asp.net 核心，而不是为了它自己的优点。

为自己说话。对于我们中的许多人来说，.NET Core 的主要好处是在服务器上摆脱了 Windows。

bradwilson 于 2017-05-08

👍11 ❤1

而且，我想，你们这些肮脏的拥有 Mac 的嬉皮士。 😝

bradwilson 于 2017-05-08

😄4

@bradwilson而且，我想，你们这些肮脏的拥有 Mac 的嬉皮士。

为自己说话，我们中的一些人不是嬉皮士;P

但是，是的，转义 Windows（或者实际上是 IIS 和 http.sys）是我想要 .NET Core 与 xcopy 部署、性能等一起使用的。

将旧代码隔离在单独的服务中或移植到 ASP.NET Core 确实会因为新的和闪亮的原因而有所回报。

adamhathcock 于 2017-05-08

@PinpointTownes是一个引用错误，如果您按照https://github.com/aspnet/Home/issues/2022#issuecomment -299810945 引用 System.Configuration 会发生什么？ EF6 说它没有依赖关系，因为一切都在 ye'olde GAC/Full Framework 捆绑包中

benaadams 于 2017-05-08

@benaadams和@PinpointTownes失败的原因是 System.Configuration.ConfigurationManager 不是 .NET Framework 期望的 DLL 名称。我不确定 System.Configuration 的端口是否有效。

      "system.configuration.configurationmanager/4.4.0-preview2-25308-01": {
        "dependencies": {
          "System.Security.Cryptography.ProtectedData": "4.4.0-preview2-25308-01"
        },
        "runtime": {
          "lib/netstandard2.0/System.Configuration.ConfigurationManager.dll": {}
        },
        "compile": {
          "ref/netstandard2.0/System.Configuration.ConfigurationManager.dll": {}
        }

davidfowl 于 2017-05-08

是的，能够运行非 Windows 服务器很棒而且很吸引人。但是如果没有 asp.net 核心，你会在它们上运行什么？甚至 .net 核心的 Nancy 也通过 kestrel、UseOwin() 等依赖于 asp.net 核心。

gulbanana 于 2017-05-08

我创建了几个不使用 ASP.NET Core 的微服务。它们就像工作进程一样，轮询队列以完成工作。

adamhathcock 于 2017-05-08

👍3

这不公平，我们遵循路线图，而您之前没有说过任何话！
如果你之前说过，我们不会在项目中使用 ASP.NET Core，因为我们需要 .NET 4.x Libs。
由于需要新功能，我们的计划包括将我们的项目更新到 ASP.NET Core 2。
我们也需要 ASP.NET Core 2 来面向 .NET 4.x。如果不可能，那么对 ASP.NET Core 1.x 的支持又如何呢？您是否打算将所有新功能也添加到它，或者只是修复错误。

ikourfaln 于 2017-05-08

由于需要新功能，我们的计划包括将我们的项目更新到 ASP.NET Core 2。

哪个？

davidfowl 于 2017-05-08

@PinpointTownes是一个参考错误，如果您按照 #2022（评论）引用 System.Configuration 会发生什么？

添加<Reference Include="System.Configuration" />没有任何效果（即抛出相同的异常），因为它似乎无法从 GAC 解决（不确定这是否真的令人惊讶，tho'）：

我不确定 System.Configuration 的端口是否有效。

所以官方的结论是......如果它使用System.Configuration ，你不能在 .NET Core 上使用为 .NET Framework 4.x 编写的库？

kevinchalet 于 2017-05-08

@PinpointTownes我什至不确定System.Configuration的版本是否正在发货（包装中的那个）。也许是，也许不是（这是从 corefx 开始的讨论）。我只是告诉你为什么你的样品打破了它的方式。

添加没有效果（即抛出相同的异常），因为它似乎无法从 GAC 解决（不确定这是否真的令人惊讶，tho'）：

AFAIK，SDK 项目中没有对 GAC 引用的默认支持。请参阅https://github.com/dotnet/sdk/issues/987#issuecomment -286307697 了解如何启用它。

所以官方的结论是……如果使用 System.Configuration，你就不能在 .NET Core 上使用为 .NET Framework 4.x 编写的库吗？

我的结论是，您应该使用上面提供的示例在 CoreFX 上打开一个问题。

davidfowl 于 2017-05-08

👍4

@davidfowl谢谢你的回复
EF Core 上一些需要的特性和助手计划在 2.0 中，特别是用于映射数据（自包含类型映射）......
反正我只要对 ASP.NET Core 1.x 的路线图有一个清晰的概念，我们的团队就很困惑和担心。

ikourfaln 于 2017-05-08

👍1

我个人正在努力解决的一件事是“稳定平台”与“新功能”的事情。一方面，我们希望平台稳定可靠和兼容，另一方面没有人愿意停留在 1.x 上，因为它没有 2.x 的特性。 ASP.NET Core 2.x 中是否有超级引人注目的功能将人们拉向那个方向，或者仅仅是因为我们拥有比 1.x 中更多的功能（因为它是新的和闪亮的）？

@davidfowl我确实认为signlarR 就是这样一个功能，它至少会出现在我之前的项目中。然而，我也认为很多担忧是由于 1.1（2018 年？）的支持窗口相对较短，如果人们确信他们可以在 asp.net 1.1 上运行，直到他们准备好切换到核心，这意味着可能，几年，和也可以覆盖一些可以让人们平静下来的补丁。

我还认为 .net core 2.0 上的 asp.net core 1.1 支持更值得强调，它为人们（我认为）提供了一个很好的迁移路径：asp.net 5 on 46 >asp.net core 1.x on 46 > .net core 2.0 上的 asp.net core 1.x > .net core 2 上的 asp.net core 2。这将是降低很多人担心的风险的途径。

aL3891 于 2017-05-08

从第一天开始，我就一直在关注这个问题，甚至在所有这些讨论和澄清之后（感谢@davidfowl ），我觉得我们中的很多人都被抛在了身后。

我理解从完整/桌面 .NET 框架中解脱出来的原因。该死，我什至同意这是增强 ASP.NET 的方式，但是我看不到现在是如何决定的，而不是从一开始就决定的。

当然，我们的客户在这两种情况下都会严重抱怨，但我宁愿“我不能使用新的闪亮的东西”，也不愿赌“我可以使用它，尽可能投资慢慢迁移和更换”，只是发现那是假的。

PabloAlarcon 于 2017-05-08

我看不到现在是如何决定的，而不是从一开始就决定的。

猜测：

在 .NET Core 1.x 上，您无法运行完整的框架库，因此这将是一个彻底的突破。

在 .NET Core 2.x 上，您主要可以运行完整框架并且可以运行 .NET Standard 1.x - 2.0 库，因此这不是一个重大突破。

在 .NET Core 2.0 上运行完整框架库的任何问题都应该在dotnet/corefx中归档

benaadams 于 2017-05-08

很明显，主要场景是“云上的现代 Web 应用程序”，它通常没有很多第三方依赖项（或者只是“代码”依赖项）。

到目前为止，大部分讨论都集中在 BCL 可用性上，但我们中的许多人依赖于第三方组件（例如与复杂视频、音频子系统的低级集成......），这些组件通常落后于 .NET 领域，而且几乎总是依赖可能最终不受支持的较低级别的技术。

使用 ASP.NET Core 1，我们正在开发我们的现代服务，针对 Libs 的 .NET 标准，并选择在完整的 .NET 或 .NET Core 上部署每个服务依赖项。

我可以打赌，因为在找到不受支持的功能/组件的情况下，我们可以轻松地针对 Full .NET。赌注是在长期平台上，因为留在 Full .NET 似乎是几年后要避免的决定。

PabloAlarcon 于 2017-05-08

👍2

_在 .NET Core 2.x 上，您主要可以运行完整框架并且可以运行 .NET Standard 1.x - 2.0 库，所以这不是一个重大突破。_

@benaadams能够使用大部分 BCL 和能够使用为完整 .NET 构建的库（并且在内部可以使用 .NET Standard 2.0 / 类型统一中不受支持的功能）之间存在很大差异。

PabloAlarcon 于 2017-05-08

我猜这个决定对缓解从 ASP.NET 4 到 ASP.NET Core 2.0 的迁移没有影响？
我管理的相当多的应用程序确实可以从 ASP.NET Core 2.0 的更新中受益，但由于 ASP.NET Core 没有 OWIN/Katana 支持，我想我需要手动迁移，而且工作量太大。 @damianh在https://github.com/aspnet/AspNetKatana/issues/27中提出了类似的建议

Tornhoof 于 2017-05-08

我们在完整的框架上运行，因为我们需要 EF6（用于空间）和目录服务，并且我们正在等待 SignalR（当前使用不受支持的版本，但它可以工作）。我有一段时间没有检查任何其他阻止程序，但可能还有更多。

据我了解，我们现在将被阻止迁移到 asp.net core 2.0 并在它出现时获取信号器。

自 dnx、RC1 到 RC2 以及将 json 项目到 csproj 以来，我们一直在努力工作，最后感觉就像我们走出了困境……现在没有那么多了。

我可以理解这种变化最终会到来，但是当 asp.net 核心试图获得牵引力时，这真的是时候吗？此外，我的直觉告诉我 EF Core 还不够成熟（当然对于空间来说还不够成熟），任何押注核心支持的人在移植库方面都承担了更大的风险……等待这个过渡的另一个版本似乎它将为 EF Core 和其他端口提供一些稳定性和机会，更不用说完整框架上的信号 r。

我敢打赌，大多数企业都在完整的框架上运行 asp.net core（顺便说一句，这很棒），并且很可能处于与我们相似的位置。

douglaswaights 于 2017-05-08

👍5

考虑到 ASP.NET Core 的快速发展，这是否意味着您将引入 LTS 和 Current 版本，以及此实例的支持长度是多少？

我想我很幸运，我正在开发一个不需要在 netfx 上运行的全新解决方案，_但是_如果可以的话，总是很高兴。对我来说，唯一会成为障碍的是我针对 netfx 的 Windows 服务，但有一个计划。

Antaris 于 2017-05-08

我觉得这种变化正朝着错误的方向发展。我知道在 netstandard 赶上之前，某些功能是核心独有的。但走这条只有核心的路线是创建一个破碎的生态系统的滑坡。

此更改表明我不确定我是否喜欢：仅针对 netcoreapp 是可以的。

hallatore 于 2017-05-08

我也想写下我的看法。

我认为现在放弃 .net 框架还为时过早。我不知道同时支持 .net framework + .net core 有什么问题，但我相信这个决定会让迁移到 AspNet Core 变得更加困难。因为有些公司认为：“让我们用 .net core 启动 AspNet Core.. 如果我们遇到严重问题（比如将来的必备库不支持它），我们总是可以回到 .net 框架”。但现在这已经不可能了，公司会犹豫是否从 AspNet Core 入手。此外，此决定可能会降低 .netstandard 的价值。

hikalkan 于 2017-05-08

@hikalkan

因为有些公司认为：“让我们用 .net core 启动 AspNet Core.. 如果我们遇到严重问题（比如将来的必备库不支持它），我们总是可以回到 .net 框架”。

不过，您始终可以使用 ASP.NET Core 1.1，对吗？

此外，此决定可能会降低 .netstandard 的价值。

我不明白为什么会这样。正如我之前所说，我们的交叉库仍然以 .NET Standard 以及需要跨所有 .NET 实现工作的 API 为目标。

davidfowl 于 2017-05-08

当然，他们可以使用 asp.net core 1.1。但不好说：“ASP.NET Core 的最新版本是 2.x，但如果你想以 .net 框架为目标，你应该使用 ASP.NET Core 1.x”。这与说“使用 MVC 5.x”没有太大区别 :)

我相信 .net 核心是未来（不是未来，即使是现在！），但放弃 .net 框架很容易（这个决定将被社区理解，就像 .net 框架正在过时一样）。

hikalkan 于 2017-05-08

👍1

不过，您始终可以使用 ASP.NET Core 1.1，对吗？

没有明显的好处。首先它还不成熟，所以这是一个赌注。
其次，ASP.Net Core 中的开发人员不希望使用旧工具编写代码并留下来。
我对几件事感兴趣。

我们已经在 ASP.Net Core、Dapper 等中完全从事绿地项目。
但在其他项目中，我们的业务逻辑在 4.6 程序集中。正如我在上面所读到的，我们引用它们应该没有问题。我希望，我理解得很好。
信号R。 DirectoryServices，MS 奥尔良，Azure。
可能与上面的对话无关，但我非常想在本地托管一个带有 Kestrel 或其他 HttpListener 的 ASP.Net Core 作为 UWP 桌面应用程序或 UWP 中的桌面桥。

stefan2410 于 2017-05-08

不得不说我对这方面的交流感到非常失望。我认为我们可以接受这个决定，但它无处不在。

7 月，我的团队开始着手开展一个为期 12 到 18 个月的新项目，该项目将在 ASP.NET Core 2.0 上运行，其中包含我们多年来在 .NET Core 中阅读的所有很酷的东西。

然而，与此同时，我们有一个 ASP.NET MVC Core 1.0 应用程序，它是我们遗留产品的中心，本质上用作调用 .NET Framework 库的包装器。

我与团队确认，他们的计划是将应用程序升级到 ASP.NET MVC Core 2.0，并在我们更换 .NET Framework 组件时让它成为新应用程序的一部分。现在我们被 ASP.NET MVC Core 1.0 困住了，在我们完成项目之前，它会被 EOL'ed。

DamienDennehy 于 2017-05-08

就在我发表我的观点之前，我只想明确一点。
如果我们想继续使用 ASP.NET Core，我是否正确假设，
我们将无法引用 .Net 4.5 或更高版本的 dll 并让它们像现在一样工作？

louislewis2 于 2017-05-08

@louislewis2不，那不正确。您将能够使用net45 - net461库，只要它们保持在netstandard2.0支持的 API 空间内。您不需要重新编译这些库。

bradwilson 于 2017-05-08

@bradwilson感谢您的澄清。那肯定会让我今晚睡得更好。
许多图书馆不在我们的控制范围内，所以这将是一个大问题。

现在松了一口气：）

louislewis2 于 2017-05-08

@shanselman @DamianEdwards @davidfowl对于我们使用的尚未移植的项目列表，将是 system.management dll 中的项目。我们专门使用硬件标识符，这用于 Azure 服务总线和我们的整个许可服务器和客户端包的自动链接生成。我想如果他们目前不是 api，会给我们带来一些严重的问题吗？

https://github.com/dotnet/corefx/issues/3324
https://github.com/dotnet/corefx/issues/14762

这是我们最大的阻碍，它让我们在整个框架上运行我们的一些应用程序。

louislewis2 于 2017-05-08

这让我们陷入了尴尬的境地。

我正在将我们的微服务从基于 Kestrel（遗留兼容原因）的 ASP.Net 4.5 自托管进程内移植到完全自托管的 ASP.Net Core 1.x。但是，我们现在需要在完整的框架上运行这些东西。这是有充分理由的。

我们有许多硬 Windows 依赖项，这些依赖项已经是我们基础架构的一部分，并且不会更改。这包括 NTLM 身份验证、事件日志记录等。如果 ASP.Net Core 2.x 放弃了对 netstandard 的支持，那么我可能根本不这样做。问题是，没有任何积极开发的完整框架替代方案。武士刀死了而且很慢（相比之下）。

如果有人可以将我指向一个与 .Net Framework 的 Kestrel 一样快的 HTTP 服务器，那么可以。但这不存在。所以我只需要接受 ASP.Net 正在让像我这样的实际生产客户落后于这种变化。

如果堆栈需要所有新的好东西，比如 Pipelines 和 Span，那么这些应该作为 netstandard 库提供。 ASP.Net Core 2.x 在 netcoreapp2.0 中使用了哪些在 netstandard2.0 中没有的 API，为什么这些 API 同时不能成为 netstandard2.0 扩展库？

mattnischan 于 2017-05-08

👍2

我们是否认真地说 MS 花了 2 年时间在其所有框架中制定（净）标准，只是为了扭转并发布不使用该标准的旗舰产品？

DamienDennehy 于 2017-05-09

😄10 👍3 👎1

由于这个问题，我认为 GitHub 团队会为问题部分添加分页功能。

ikourfaln 于 2017-05-09

👍7

@mattnischan

我正在将我们的微服务从基于 Kestrel（遗留兼容原因）的 ASP.Net 4.5 自托管进程内移植到完全自托管的 ASP.Net Core 1.x。但是，我们现在需要在完整的框架上运行这些东西。这是有充分理由的。

您可以继续使用 ASP.NET Core 1.x 对吗？

如果堆栈需要所有新的好东西，比如 Pipelines 和 Span，那么这些应该作为 netstandard 库提供。 ASP.Net Core 2.x 在 netcoreapp2.0 中使用了哪些在 netstandard2.0 中没有的 API，为什么这些 API 同时不能成为 netstandard2.0 扩展库？

当 API 出现在 .NET Standard 中但不在 .NET Framework 中时，您将如何使用它们？

davidfowl 于 2017-05-09

@stefan2410

您可以为此使用 ASP.NET Core 1.x 吗？您需要哪些 ASP.NET Core 2.0 功能？只是SignalR吗？

davidfowl 于 2017-05-09

在接下来的两年内保持该应用程序不变，但在完成后将 .NET Framework 库替换为其 .NET Core 等效项。这将使我们的业务逻辑等在两个应用程序之间共享。
我们不能这样做，因为 2018 年 7 月是 ASP.NET MVC Core 1.0 支持的截止日期。

再一次，在我假设的世界里，我们延长了 1.x 的生命周期

将应用程序升级到 ASP.NET MVC Core 2.0，并在我们更换 .NET Framework 组件时让它成为新应用程序的一部分。
我们也不能这样做，因为 Core 2.0 不支持 .NET Framework，所以要么全有，要么全无。

你真的需要 ASP.NET Core 2.0 吗？还是只是 .NET Core 2.0？

davidfowl 于 2017-05-09

当 API 出现在 .NET Standard 中但不在 .NET Framework 中时，您将如何使用它们？

我们的计划是：等他们进去。你之前说过这只是时间问题，对吧？为了稳定起见，将前沿滞后一些固定数量会很好。至少比永远落后要好得多。

gulbanana 于 2017-05-09

@davidfowl
我将搬入 ASP.Net core 2.0。我没有其他解决方案。我不能说让团队落后于进化，我们等了很长时间的 ASP.Net Core。
只要我们的业务逻辑 4.6 程序集引用没有问题。
我需要 SignalR、DirectoryServices，而不是 Azure/Amazon 库、MS Orleans 的问题。
也可能与上面的对话无关，但我希望桌面应用程序在本地托管一个带有 Kestrel / HttpListener 的 ASP.Net Core 作为 UWP 桌面应用程序或 UWP 中的桌面桥。
我们不能为 XAML 重写代码，我不想使用 Electron。

stefan2410 于 2017-05-09

您可以继续使用 ASP.NET Core 1.x 对吗？

在什么时间范围内？我看不到像事件日志这样的东西使它成为网络标准。

当 API 出现在 .NET Standard 中但不在 .NET Framework 中时，您将如何使用它们？

这是一回事吗？根据文档，netstandard20 似乎仍在 net461 上运行。您是说 netstandard20 下的 API 还不够完整，无法实现新的好东西？或者，是否有计划将 netstandard 移出尚未公开的框架？

mattnischan 于 2017-05-09

我们的计划是：等他们进去。你之前说过这只是时间问题，对吧？为了稳定起见，将前沿滞后一些固定数量会很好。至少比永远落后要好得多。

可以在标准之上编写库。当标准本身的内容需要更改时，将需要更长的时间才能在 .NET 的所有实现中采用，其中包括 .NET Framework。这可能意味着几件事：

.NET Standard 将以最慢的实现速度发展
.NET Standard 将以其他速度发展，而 .NET Framework 将是最后一个赶上的。

当然，这并不意味着不能针对它编写库，只是意味着在选择要支持的 .NET Standard 版本时需要考虑这些警告。

davidfowl 于 2017-05-09

👍1

也可能与上面的对话无关，但我希望桌面应用程序在本地托管一个带有 Kestrel / HttpListener 的 ASP.Net Core 作为 UWP 桌面应用程序或 UWP 中的桌面桥。

UWP 上的 ASP.NET Core 目前没有任何路线图，所以我真的不能说这里会发生什么。 HttpListener是 .NET Standard 2.0 的一部分，所以也许有可能会起作用。

davidfowl 于 2017-05-09

我想花一点时间在这里感谢大家的评论和反馈。在我们找出前进的道路时，我们非常感谢您的耐心和耐心。请注意，我们并不打算让这个变化如此艰难、如此晚，而且没有任何警告。事后诸葛亮是 20/20，如果我们知道我们现在所知道的，我们会更早地沟通事情。我们会更加努力地前进。

我们有一个基于我们在这里收到的反馈的计划，我想在本周晚些时候将其发布为 2.0.0-preview1 版本的公告之前与您分享。发生这种情况时，我们将打开一个新问题以促进围绕该计划的讨论，但现在继续并继续在这里分享您的想法和反馈：

.NET Framework 上对 ASP.NET Core 1.x 的支持将至少再延长一年（至 2019 年 7 月）。我们将每年重新评估这一点，并承诺在结束对 ASP.NET Core 1.x 的支持之前提供 12 个月的通知（因此，到 2018 年 7 月，我们将宣布我们是否将再延长 12 个月至 2020 年 7 月）（旁注：是我们已经在谈论 2020 年这一事实让其他人感到害怕吗？不？好吧，只有我。 ）
新的 SignalR 将针对 ASP.NET Core 1.x（今年晚些时候推出）并得到全面支持
我们将继续更新 ASP.NET Core 1.x 以支持新的语言版本等，就像我们为System.Web所做的那样
在 .NET Core 1.x 上运行的 ASP.NET Core 1.x 将支持到 2018 年 7 月（无变化）
只要支持 .NET Framework 上的 ASP.NET Core 1.x，就会支持在 .NET Core 2+ 上运行的 ASP.NET Core 1.x
- 这是为了确保在受支持的 .NET Core 上始终存在受支持的 ASP.NET Core 重叠，而我们支持在 .NET Framework 上运行，从而允许客户随着时间的推移进行移植，同时保持受支持的位
.NET Core 1.x 支持（作为运行时）不会改变。于 2018 年 7 月结束。运行 ASP.NET Core 1.x 的客户需要迁移到 .NET Core 2.0 或此时使用 .NET Framework（或迁移到 .NET Core 2.0 上的 ASP.NET Core 2.0）
今年我们将把System.DirectoryServices和System.Drawing移植到 .NET Core（完全支持，跨平台，至少在夏季预览 Windows）
之后要移植到 .NET Core 的内容列表目前包括ServiceBase （以支持 .NET Core Windows 服务）。除了下一个时间表之外，还没有时间表（随着我们在列表中的工作，时间表显然变得更加具体）。我们将根据客户反馈在此列表上进行构建。
我们目前没有将System.ServiceModel （服务器端 WCF）移植到 .NET Core 的计划。 .NET Core 的 WCF 可能会继续得到增强，并会根据反馈添加一些功能，例如 HTTP 消息加密。

DamianEdwards 于 2017-05-09

👍31 😕3 👎1

@DamianEdwards @davidfowl问题的很大一部分是，它可能需要数月的计划和开发工作，同时牺牲巨大的机会成本来承诺迁移到 ASP.NET Core，而许多组织将无法继续迁移。 .NET 4.x，因为它是唯一可以确保他们能够运行所有系统依赖项的平台。

到目前为止，MS 一直在积极地将 .NET Core 作为 ASP.NET 的未来进行营销，目前尚不清楚 ASP.NET 4.x 的开发是否已经停止，以及是否所有未来的开发工作都将投资于 ASP.NET Core，所以将进行大量迁移以使其系统保持最新状态。如果他们所有努力的最终结果是他们有效地迁移到了 EOL ed 平台，那么很多人会觉得他们被丢在了公共汽车下。这将伤害到组织以及开发人员/顾问，他们是发起迁移到 .NET Core 的最大拥护者。他们现在可能不需要 ASP.NET Core 2.0 中的任何东西，但他们肯定会希望为他们的系统留出一些空间，并能够为他们所有的努力访问一些新功能。

我也不明白为什么现有的“遗留”代码在 IMO 应该被认为是 .NET 最伟大的资产之一时被认为是一种负担，如果.NET Core 不能运行现有的.NET 库，它就远没有那么吸引人了. Java 之所以如此强大，是因为 JVM 庞大而稳定的生态系统，这比语言本身固有的弱点更重要。

我认为 MS 甚至没有开始感受到放弃 .NET 4.x 支持的强烈反对，这种支持在宣布之前不会广为人知，我希望大多数积极关注 GitHub 开发的开发人员对看到新功能更感兴趣它们具有互操作性，并确保现有代码库的迁移路径顺畅。我会感到非常惊讶，但如果在宣布这一决定后你没有从这个决定中得到任何热度，那么它可能是正确的，因为也许不会有那么多人因此受到伤害。

专注于 ASP.NET Core 2.0 稳定/兼容版本，然后为后续版本宣布仅 .NET Core 的未来是否过于努力？鉴于这是完全无法预料的，似乎在这种情况下这样做是公平的。

mythz 于 2017-05-09

👍20

@DamianEdwards感谢更新和明确的计划。我不同意它，但我仍然感谢你提出来。

这里仍然存在巨大的基本差距。 1.x 的移植几乎完全是横向移植，对我们来说几乎没有什么特性。 2.x 是一些值得升级的地方，但我们仍然不能保证我们能做出这样的举动。很有可能我们花费了大量的时间、金钱和精力来移植到 1.x，但由于完全的框架依赖性而被困在那里。我不会和我们公司赌博。我们最终得到的支持可能比现在对 ASP.NET 4.x 的支持要少。

除非这种情况发生变化，否则我们的应用程序将不会使用 ASP.NET Core，而且我们所有的库都会因为缺乏 dogfooding 而变得更糟。

我真诚地希望你重新考虑这个决定。我希望有一天我们可以让 Stack Overflow 充分利用我们为帮助开发 .NET Core 平台而投入的数千个个人时间。

NickCraver 于 2017-05-09

👍32

@尼克克拉弗

很有可能我们花费了大量的时间、金钱和精力来移植到 1.x，但由于完全的框架依赖性而被困在那里。

在整个线程中，您将 System.DirectoryServices 称为核心内容之一。我假设您有一些依赖项，您认为这些依赖项需要很长时间才能移植或永远不会移植。如果 2.0 支持 .NET Framework，这些依赖项会在一年内迁移吗？

2.x 是一些值得升级的地方，但我们仍然不能保证我们能做出这样的举动。

哪个？很高兴知道，因为我们正在讨论将一些非常重要的东西移植回 ASP.NET Core 1.1 以简化过渡。

除非这种情况发生变化，否则我们的应用程序将不会使用 ASP.NET Core，而且我们所有的库都会因为缺乏 dogfooding 而变得更糟。

我对 stackoverflow.com 一无所知，但是否可以拆分（我不想说“微服务”）以便 ASP.NET Core 可以用于某些部分？

davidfowl 于 2017-05-09

@mythz

这将伤害两个组织以及开发人员/顾问，他们是发起迁移到 .NET Core 的最大拥护者

你是说 ASP.NET Core 吗？还是 .NET 核心？

davidfowl 于 2017-05-09

@davidfowl我的意思是 ASP.NET Core，但它也会影响计划先从 ASP.NET Core/.NET 4.x 分阶段迁移，然后再从 .NET Core 迁移的开发人员。

mythz 于 2017-05-09

说到这，我注意到 ASP.NET Core/.NET Core 上没有用于处理 SAML 的库。我需要通过第三方 IdP 处理 SSO，但我不知道这是否可行。

snickler 于 2017-05-09

@davidfowl我的意思是 ASP.NET Core，但它也会影响计划先从 ASP.NET Core .NET 4.x 分阶段迁移，然后再从 .NET Core 迁移的开发人员。

我不明白为什么会这样。

davidfowl 于 2017-05-09

我认为该计划可能足以让我的组织避免离开平台。主要的是有更长的支持时间（=安全补丁），在此期间剩余的 netfx 依赖可以被重写或以其他方式消除。不过，这一切仍然有点冒险，而且在概念上很奇怪。如果三年后我们想要建立一个可以摄取 Excel 文档或在应用程序中嵌入网络服务器的网站会怎样？建立在标准之上而不是 netcoreapp 之上的其他框架（如 Orleans）会发生什么？

我真的不明白为什么在 netstandard2.0 上做了这么多工作，如果它永远都不够好，让 ASP.NET Core 实际使用它。

gulbanana 于 2017-05-09

👍2

如果三年后我们想建立一个可以提取 Excel 文档的网站会发生什么

很难说。我不能代表拥有它的团队，但也许它会被移植到 .NET Core 并且可以跨平台工作。

或在应用程序中嵌入网络服务器？

HttpListener是 netstandard 2.0 的一部分。

建立在标准之上而不是 netcoreapp 之上的其他框架（如 Orleans）会发生什么？

由框架决定是否要在 .NET Framework、UWP、.NET Core、mono 等上运行。这是一种选择。 Orleans 不附带 .NET Core。 ASP.NET Core 可以。那些产品是一样的。

davidfowl 于 2017-05-09

对我们（和我们的客户）来说，艰难的决定与我今天拥有的图书馆无关，而是关于我不知道从现在起是否需要 6 个月的图书馆。有很多库和框架还不支持netstandard 。例如，在进行一个项目的一个月后，我们意识到我们需要 NHibernate 中的一些功能，这些功能在 EF6 中甚至都没有，更不用说 EF Core。那么我的选择是什么 - 在完整的 .NET 上以 ASP.NET Core 1.x 为目标？

看起来我将来会有一些 ApiPort。

jbogard 于 2017-05-09

👍7

那么我的选择是什么 - 在完整的 .NET 上以 ASP.NET Core 1.x 为目标？

是的。

davidfowl 于 2017-05-09

很难说。我不能代表拥有它的团队，但也许它会被移植到 .NET Core 并且可以跨平台工作。

没错，但肯定是在 asp.net 团队的职权范围内，可以决定是否值得提供对可能未移植的库的生态系统的访问。

gulbanana 于 2017-05-09

没错，但肯定是在 asp.net 团队的职权范围内，可以决定是否值得提供对可能未移植的库的生态系统的访问。

.NET 又大又老，你不可能不能指望 ASP.NET 团队能说出 .NET 生态系统中存在的库的气息。这是不现实的。我刚刚了解到 CSOM (https://msdn.microsoft.com/en-us/library/office/jj163123.aspx) 是该线程的一部分，我怀疑它会被移植，但我不能这么说当然。

在 .NET Framework 上扩展对 ASP.NET 1.1 的支持有助于缓解这一点，但我认为它也有帮助，因为需要隔离一些依赖项才能正确迁移到 .NET Core 上的 ASP.NET Core（这是预期的未来）。

davidfowl 于 2017-05-09

我将把图书馆放在一边，因为这一点已经详细讨论过了。在我们的案例（amilia.com，电子商务 SaaS）中，第三方工具已经是一个很好的选择，我们目前甚至无法在完整的框架上运行 ASP.NET Core。我承认这听起来不是一个正当的理由，但它是我们必须处理的一个约束。

理论上，我们可以用支持 .NET Core 的替代工具替换这些工具（即分析器、监控、构建服务器等），但我宁愿花几个月的时间来解决更紧迫的问题。我们最终会迁移到 ASP.NET Core/.NET Core，但现在它是一个非常移动的目标。

plmaheu 于 2017-05-09

到目前为止，人们一直期望 ASP.NET Core能够继续在桌面框架上运行，从而涉及到等方面的广度。我不知道我们应该阅读什么样的茶叶才能知道那是不现实的：/

就像，要明确一点：ASP.NET Core 可能只在 .NET Core 上运行的想法本身并不疯狂，但我们以前从未听说过它。所有公开信息都是它在 .NET Framework 上运行良好，并且没有迹象表明这可能需要改变。

gulbanana 于 2017-05-09

👍3

.NET 又大又老，你不可能指望 ASP.NET 团队能说出 .NET 生态系统中存在的库的气息。这是不现实的

这难道不是继续支持 .NET 4.x 的好理由吗？兼容性/互操作性的负担可以包含在 .NET 4.x 平台上，它可以是一个可行的解决方案，可以减轻 .NET Core 与旧库互操作的需要，并减轻将现有流行的 .NET 库移植到 .NET Core 的压力（对于 MS 和外部作者）。

mythz 于 2017-05-09

👍1

@mythz

这难道不是继续支持 .NET 4.x 的好理由吗？兼容性/互操作性的负担可以包含在 .NET 4.x 平台上，它可以是一个可行的解决方案，可以减轻 .NET Core 与旧库互操作的需要，并减轻将现有流行的 .NET 库移植到 .NET Core 的压力（对于 MS 和外部作者）。

这就是为什么 ASP.NET Core on 1.1 的生命周期已经延长（尽管不是永久的）。我们将确保 SignalR 正常工作，因为这是使用 ASP.NET Core 2.0 的主要原因之一。同时，从长远来看，它并不是 ASP.NET Core 想要的。其目的始终是作为统一 .NET Core 平台的一部分发布。

@gulbanana

到目前为止，人们一直期望 ASP.NET Core 能够继续在桌面框架上运行，从而涉及到等方面的广度。我不知道我们应该阅读什么样的茶叶才能知道那是不现实的：/

不幸的是，.NET Framework 上的 ASP.NET Core 从未作为缓解移植的权宜之计解决方案进行交流（这是我们非常糟糕的消息）。它从未打算永远作为受支持的平台，如果您假设某些依赖项永远不会被移植，这是合乎逻辑的结论。

davidfowl 于 2017-05-09

这就是为什么 ASP.NET Core on 1.1 的生命周期已经延长（尽管不是永久的）。

问题是这是否足够，当前版本基本上在兼容/稳定版本交付之前就已经 EOL 了。

我不认为正在考虑现有投资的价值，谁会愿意通过所有努力迁移到 EOL 平台？开发人员将无限期地在他们现有的棕地系统上工作，他们基本上被告知他们当前的 ASP.NET v4.x 技能将变得过时，并且他们无法迁移到新的 ASP.NET Core 开发模型，因为 . NET 4.x 支持正在被放弃，他们考虑或建议迁移到死胡同平台是不负责任的。

mythz 于 2017-05-09

👍1

@davidfowl

不幸的是，.NET Framework 上的 ASP.NET Core 从未作为缓解移植的权宜之计解决方案进行交流（这是我们非常糟糕的消息）。它从未打算永远作为受支持的平台，如果您假设某些依赖项永远不会被移植，这是合乎逻辑的结论。

发生错误，那很好。现在的问题是，许多人做出了这种假设，因此只使用 ASP.NET Core，因为他们的结论合乎逻辑但错误。我们会看到有多少，我猜：/

gulbanana 于 2017-05-09

我等asp.net core 2/.net core 2 等了那么久，结果好郁闷。

xyting 于 2017-05-09

@mythz

我不认为正在考虑现有投资的价值，谁会愿意通过所有努力迁移到 EOL 平台？

明年 ASP.NET Core 2.0 在 .NET Framework 上 EOL 3.0 出来的时候，不能提出同样的论点吗？如果您说在 ASP.NET Core 1.1 上一年还不够，为什么您会建议在 ASP.NET Core 2.0 上一年就可以了？

开发人员将无限期地在他们现有的棕地系统上工作，他们基本上被告知他们当前的 ASP.NET v4.x 技能将变得过时，并且他们无法迁移到新的 ASP.NET Core 开发模型，因为 . NET 4.x 支持正在被放弃，他们考虑或建议迁移到死胡同平台是不负责任的。

谁知道 ASP.NET 4.x 技能会过时？如果有什么我们希望他们不是。 MVC 特别吹捧与一些新功能的概念兼容性。 ASP.NET Core 看起来很像 Katana（这不是错误的）。如果您在谈论 Web 表单，那么 MVC 呢？

我没有任何咨询经验，但我同意如果依赖项不可用，那么我会同意。无论是那个还是应用程序都需要重新设计以考虑到这一点。

davidfowl 于 2017-05-09

@xyting你能澄清一下吗？

davidfowl 于 2017-05-09

@davidfowl

明年 ASP.NET Core 2.0 在 .NET Framework 上 EOL 3.0 出来的时候，不能提出同样的论点吗？如果您说在 ASP.NET Core 1.1 上一年还不够，为什么您会建议在 ASP.NET Core 2.0 上一年就可以了？

长期以来，我一直认为 ASP.NET Core 1.1 只是 ASP.NET Core 2.0 和 .NET Standard 2.0 的权宜之计，这将是一个以兼容性为重点且稳定的 LTS 版本，将弥补与大多数.NET 4.x 中缺少的核心功能——直到这个线程基本上破坏了这个假设。保持 .NET 4.x 与 ASP.NET Core 2.0 的兼容性并不理想，但它比在当前版本中终止它要好得多，这是没有人预料到的。

谁知道 ASP.NET 4.x 技能会过时？如果有什么我们希望他们不是。

MS 在 .NET Core 上进行了所有积极的营销，所有新公告和功能似乎都以 ASP.NET Core 为重点。旧的 ASP.NET WebForms/MVC 是否正在公开开发？在旧的 ASP.NET WebForms/MVC 与 .NET Core 上投入了多少开发工作？我不知道，我最近看到的所有内容、所有每周站立会议、视频教程似乎都只关注 ASP.NET Core。我知道我肯定不愿意使用旧的 ASP.NET WebForms 或 MVC 技术开始新的未开发项目。

如果您希望他们不是 MS，那么绝对应该通过清晰的路线图更好地传达这一点。鉴于过去几年 ASP.NET 的波动性（这个问题就是一个很好的例子），如果没有官方承诺和公告，就不可能知道未来会怎样。

mythz 于 2017-05-09

👍5

有没有其他人觉得如果版本 1 从未在完整框架上运行会更好？我没想到它是因为命名。现在它做到了，而且我尝到了味道，我很失望失去它。

我确实知道你从哪里来，你想尽可能快地迭代整个堆栈。您正在与一大堆控制整个堆栈并且没有包袱拖累的绿色领域网络框架竞争。放下 System.Web 的包袱是 ASP.NET Core 如此令人兴奋的主要原因之一。

睡了之后我可以说我们的使用会很好，我们需要的依赖项都应该在 2.0 上工作。

jkells 于 2017-05-09

👍9

同时，从长远来看，它并不是 ASP.NET Core 想要的。其目的始终是作为统一 .NET Core 平台的一部分发布。

虽然不需要通灵就能发现 .NET Core 是 .NET 未来的平台……如果从一开始（或者如您所说的“始终”）的意图就是将 ASP.NET Core 与 .NET 结合起来。 NET 核心，这绝对没有在我见过的任何媒体中传达过。

我确实看到了每一个 ASP.NET 站立会议的每一分钟（包括 Hanselman 和 Glenn 用 3 个小时对 Docker 进行故障排除......因为我没有生命），我阅读博客，我总是在 Twitter 上，我去一年 2 次以上的会议，参加用户组等，我从未听说过将其作为 ASP.NET Core 的意图进行交流。 相反，我一遍又一遍地听到“它在两个平台上运行”，而且，理所当然地，人们觉得有人把椅子从他们下面拉了出来。我什至曾就 ASP.NET Core 发表过演讲，并说“它可以在两个平台上运行”，现在我为我所带领的任何人感到内疚。我会说 ITT 的人可能处于最前沿，并且最能接受这种新闻，而且这里有很多反对意见。这似乎只会变得更糟，因为这个消息会传播到开发人员和他们的经理，他们没有那么投入，并且可能比那些 ITT 更保守。

除了缺乏沟通和缺乏对某些场景的支持之外，我认为很多反弹只是由于这个公告的时机。 .NET Core 2 甚至还没有 RTM，它已经被认为是唯一的长期前进道路，而且基本上已经在 ASP.NET Core 的完整框架上放置了一颗定时炸弹。我认为，一旦我们除了夜睡之外还有一些有形的东西可以玩，我们的很多恐惧都可以消除。

我确实认为在 VS 中从 .NET Core 2+ 引用 net461+ 库时，需要有比“运行它并查看它是否有效”更好的工具体验，因为我已经可以看到“我们可能运行大部分你的 461+ 组件也是！” 将被推销至死。可以分析我们引用的缺失 API 的东西，提供编译时错误，理想情况下甚至建议 compat nupkgs（如果存在）（如上面 EF6 示例中的 System.Configuration ......并让它工作:smile:)。显然，并不是所有的东西都可以在编译时进行分析（上面提到的分布式事务场景是难以提前分析的），但越多越好。有点像Immo 在这里为PlatformNotSupportedException所做的事情，而 netstandard2 缺少的 net461 API会很好。

只是我的2美分。我希望我只是反应过度。最终，我们中的很多人都感到失望，因为我们喜欢 ASP.NET Core，并且我们不希望有任何东西妨碍我们使用它。 ❤️

scottsauber 于 2017-05-09

👍48 😄1

加入我对已经列出的担忧的声音，我们将在下个月开始一个新的 ASP.NET MVC 项目，它将是带有 ASP.NET MVC 的普通 .NET 框架，因为客户不相信微软在以下方面做正确的事情长期规划。

客户组织仍在使用 Windows 7 部署，这个项目是一个例外，因为他们的大多数 Web 项目实际上是在 UNIX 上使用 Java 完成的，而 .NET 主要用于桌面应用程序。

这种类型的不确定性只是堆积了 Windows 8 .NET 堆栈和 UWP 的破败历史，增加了组织 CTO 寻找 .NET 未来更稳定替代品的兴趣。

如果你强迫这些类型的组织从头开始编写模块以在 ASP.NET Core 上工作，我也可以建议我们的客户采用更稳定的路线图，而不是因为我无法控制的问题而丢脸。

pjmlp 于 2017-05-09

@davidfowl可能这种更改适用于 99% 的项目。但它被出售为“它在两个平台上运行”和“如果需要，你可以将它与完整的框架一起使用”。大家都知道asp.net core的完整框架版本是为不能迁移的项目准备的，没问题。人们在计划时就考虑到了这一点。

这种变化在代码方面可能不是最糟糕的，但当更多的普通开发人员看到这个消息时，它很可能会引发一场巨大的狗屎风暴。它与代码无关，而与所承诺的有关。承诺是“运行网络或核心，网络标准将它们结合起来”。

hallatore 于 2017-05-09

👍3

@DamianEdwards @davidfowl感谢您分享计划。

1.x 上的 SignalR 是替换我们不支持的版本以及 ServiceBase 是下一个列表中下一个的消息，因为我们目前也在使用它！

我们严重依赖 EF6 和空间，所以我们将停留在 1.x 上，直到它拥有我们需要的功能集......

然而，在一个半有趣的旁注中，这最终可能会迫使为此进行更多的微服务部署。我不会期待解释为什么我们的 LOB 客户需要在 IIS 上安装更多的 api 才能让我们的产品正常工作......

我真的希望这可以推迟，因为似乎为时过早，正如一些人提到的那样，当博客文章下降时，这将产生巨大的反弹。

另外我必须说，当我从一开始就认为这将在完整的框架上运行并且一直在向同事宣扬同样的事情时，我感到有点被抛售了。虽然解释了 asp.net core 令人困惑的命名选择。

douglaswaights 于 2017-05-09

@shanselman @davidfowl我最大的痛点是 NHibernate。即使在 EF Core 发布之后，它仍然是唯一最先进的全功能 O/R 映射器。

fubar-coder 于 2017-05-09

@shanselman @DamianEdwards我正在考虑将站点从 ASP.NET MVC 4 升级到最新版本（我很困惑是 5 还是 1）。我仍然需要运行完整的 .net 框架，因为我同时引用了 SyncFusion 和 Telerik 库。 SyncFusion 显示 PDF 文件和 Telerik 生成 word .docx 文件。正如其他人所指出的那样，微软处理这个问题的策略是“试试看它是否有效”是不合理的。我不能保证和生产一切都会正常工作，因为它是第三方代码的庞大代码库。

虽然 SyncFusion 支持通常非常好 Telerik 的支持不是，如果他们可以使其与 .net 核心一起使用，我会感到惊讶。我不知道他们可能使用的是什么 API，而 .net 核心不支持 - 作为最终用户，这就是第三方产品的全部意义所在，我只需将其插入，它就可以完成它需要做的事情。

坦率地说，对于一个不经常处理这些东西的客户（我主要做 WPF），这一切都非常令人困惑。有太多不同的版本，有各种不兼容的地方。正如有人指出的那样，它有点像 UWP XAML - 类似但与 WPF XAML 完全不兼容。

对开发人员不利，只是导致开发人员对微软失去信任的另一件事（过去几年中的许多事情之一）。在我看来，ASP.NET 绝对应该在完整的 .net 框架上运行，因为人们可能需要在他们的服务器上使用如此庞大的工具库。就我而言，如果我需要更新到更高版本的 .net 框架，我可以轻松地更新到新版本的 ASP.net 功能，以便使用最新的 ASP.net 内容。

在人们完全跳槽之前，向开发人员发送的任何消息都需要更加清晰。

...斯蒂芬

stefanolson 于 2017-05-09

👍5 ❤1

不幸的是，.NET Framework 上的 ASP.NET Core 从未作为缓解移植的权宜之计解决方案进行交流（这是我们非常糟糕的消息）。它从未打算永远作为受支持的平台，如果您假设某些依赖项永远不会被移植，这是合乎逻辑的结论。

我个人对此问题中列出的更改没有问题，我理解其中的原因并且它们是有道理的，因为我已经阅读了这里的很多回复。但是，您刚才所说的突出了问题的最终症结所在 - 整个 Microsoft 的沟通不畅（我很欣赏这不是您或任何_特定_个人的错）。

也许我遗漏了一些东西，但是“在开放中开发”不仅仅是在 github 上提供代码供每个人浏览和使用。之所以会出现这个问题，是因为有一天代码中出现了让人们大吃一惊的变化，但很明显，您和 .net 团队中的每个人都知道并理解它——所以这是一个很长的时间。问题是，我们这些普通人完全被它蒙蔽了双眼。

更糟糕的是，我怀疑大多数开发人员并没有过多关注 github 来获取他们的知识和信息——所以这个变化会让更多的人感到惊讶，而不是已经在这里发表评论的人。我自己才发现这个问题，因为它出现在我的hackernews RSS 提要上——这不是我所谓的新闻和信息的主要来源。

任何关注 MSDN 上博客文章的人都会知道 2.0 即将到来，他们会将其视为弥合 asp.net 核心与之前“缺失”的一切之间差距的圣杯，但他们完全不知道对于某些工作流程来说，这本质上是一个重大变化。关于 asp.net core 2.0 的设计真正发生了什么的细节很少。我怀疑本周晚些时候会在 Build? 一个人只能希望。

.net slack 是另一种信息资源，但要及时了解最新情况有点麻烦。它非常适合开发人员参与和提问，但它几乎不是新闻来源。

Twitter 和社交媒体是另一种信息来源，但当它出现时又有点像这个 github 问题，这通常是因为有人对已经做出的决定提出了担忧，并让人们感到意外。

这也不是我们第一次遇到这个确切的问题。还记得改回csproj造成的惨败吗？我不想参与关于这个变化的辩论，但这是另一个让人们感到惊讶的变化的例子，它的沟通非常糟糕，以至于直到今天，很多人根本没有意识到它不是同一个 csproj从“糟糕的过去”开始。

我不完全确定我想在这里提出什么建议，但 .net 的开放式开发肯定有一些“缺失”的东西。 Microsoft 在为开发人员提供资源和文档方面做得很好，但仅限于成品和已交付的东西。路线图、计划会议以及决定框架设计和方向的一切似乎都是在闭门造车的情况下完成的，偶尔会提到“精选合作伙伴”等。我并不是说每次会议都应该在全球范围内进行流式传输和广播，但绝对可以有一个更好的中间地带，使所做的决定及其背后的理由尽早以一种简单的方式传达给社区对于我们这些真正_想要_跟随消化并保持领先的人。可能是 MSDN（或其他地方）上的专门博客，在做出这些决定时会定期更新。

neoKushan 于 2017-05-09

👍11

我最大的问题之一是，在去年几乎所有 ASP.NET Core 会议上，您都向它展示了一张幻灯片，显示在 .net 框架和 .net 核心上运行的 asp.net 核心，只是看看这个：去年探索使用来自 Ignite 的 Microsoft ASP.NET Core 1.0 进行 Web 开发。在大约 7.50 时，您将看到幻灯片。

对我来说最大的亮点是 System.DirectoryServices、ServiceBase、EF6（EF Core 尚未准备好）、ClosedXML（用于创建 excel 工作表）。

Sjark 于 2017-05-09

👍1

.NET Framework 上对 ASP.NET Core 1.x 的支持将至少再延长一年（至 2019 年 7 月）。我们将每年重新评估这一点，并承诺在结束对 ASP.NET Core 1.x 的支持之前提供 12 个月的通知（因此，到 2018 年 7 月，我们将宣布我们是否会再延长 12 个月至 2020 年 7 月）（旁注：是我们已经在谈论 2020 年这一事实让其他人感到害怕吗？不？好吧，只有我。）

@DamianEdwards感谢您的公告。

目前，我们公司正在为多个使用 .NET Framework 4.6.2 上的 ASP.NET Core 1.1 的客户开发企业应用程序。听说对该框架组合的支持至少会支持到 2019 年，并且可能会延长到 2020 年，这让我松了一口气。

今年我们将 System.DirectoryServices 和 System.Drawing 移植到 .NET Core（完全支持，跨平台，至少在夏季预览 Windows）

这是我们现在针对 .NET Framework 的两个唯一原因。如果这些都完全移植到 .NET Core 2，我相信明年我们可以安全地将我们的应用程序移植到 ASP.NET Core 2。

ryanelian 于 2017-05-09

👍1

似乎很多人都打破了成为 MS 开发人员的基本规则——至少在 V2 之前不要承诺任何产品/分叉。

但是，是的，谈论疏远您的企业客户！他们使用 MS 的全部原因是为了向后兼容。

大多数运行 ASP.NET 的人并不关心它是否在 linux 上运行。如果他们看到一篇博客文章，与 ASPNET Core 进行速度比较，如果他们看到它不支持旧版 .NET，他们甚至都不会阅读过去的跨平台。

哈哈。

captainjono 于 2017-05-09

👍4

我认为让 ASP.NET Core 2.0 在 net46x 上完全运行是有价值的，因为它可以为许多人提供通往新世界的顺利迁移路径。我想很多人都在等待 ASP.NET Core 2.0 和 .NET Core 2.0，希望它能弥补当今的许多差距并允许迁移。如果 ASP.NET Core 2.0 需要将所有内容都移植到 netcoreapp2.0，那么这对团队来说将是一个巨大的减速，甚至可能会危及可行性。

但是，这并不意味着 ASP.NET Core 3.0 不久之后将只针对所有从事所有新的、闪亮的、未开发的东西并希望走上快车道的人的 netcoreapp2.0。

并排拥有两个版本的 ASP.NET Core（2.0 和 3.0）确实是一件好事（至少在一段时间内）。这可以让 MSFT 更快地淘汰当前的 MVC 5 堆栈，因为新版本的 MVC 本质上是 ASP.NET Core MVC 2.0，它也可以在完整的 .NET 上运行。

dustinmoris 于 2017-05-09

👍4

我认为让 ASP.NET Core 2.0 在 net46x 上完全运行是有价值的，因为它可以让很多人顺利迁移到新世界

什么比从 ASP.NET Core 1.x 移植更流畅？

我想很多人都在等待 ASP.NET Core 2.0 和 .NET Core 2.0，希望它能弥补当今的许多差距并允许迁移。

为使事物兼容而完成的大部分工作是在 .NET Core 2.0 和 .NET Standard 2.0 中完成的。 ASP.NET Core 2.0 确实没有那么多新功能。据说我们要将 SignalR 反向移植到 ASP.NET Core 1.x（无论如何都是 2.0 之后的版本）。它只是一个感知的东西吗？

并排拥有两个版本的 ASP.NET Core（2.0 和 3.0）确实是一件好事。

这就是我们对 1.1 和 2.0 所做的（只需翻转数字）。

这可以让 MSFT 更快地淘汰当前的 MVC 5 堆栈，因为新版本的 MVC 本质上是 ASP.NET Core MVC 2.0，它也可以在完整的 .NET 上运行。

MVC 5 永远不会消失，我们不会弃用任何东西。只要 .NET Framework 存在，它就会受到支持。您仍然无法在 IIS 集成管道（在 System.Web 上）内运行 ASP.NET Core 项目，并且它不会在 System.Web 上执行与 MVC 5 相同的所有操作，因此它确实不能替代某些场景.

davidfowl 于 2017-05-09

@davidfowl我是否能够创建一个面向完整 .NET 和 netcoreapp2.0 的 ASP.NET Core 1.x 应用程序，以便我可以首先将当前的旧应用程序迁移到 ASP.NET Core，所有依赖项都是 net46x，然后慢慢迁移一个接一个地以 netstandard2.0 为目标，直到一切都在 netstandard2.0 上，这将允许我将 ASP.NET Core 1.x 应用程序升级到 2.x（并作为其中的一部分删除 net46x 的目标）？

如果是，那么我想我误解了这个线程。我认为这确实是大多数人在这里所追求的。

dustinmoris 于 2017-05-09

👍2

@dustinmoris是的，您可以这样做。人们主要担心的是，如果他们在 ASP.NET Core 1.x 支持结束之前没有迁移到 ASP.NET Core 2.x 会发生什么，如果他们有可能迁移的话。

alexwiese 于 2017-05-09

👍1

@alexwiese啊，好吧，那太好了，那么我们现在到底在讨论什么？与其讨论目标框架，不如讨论 ASP.NET Core 1.x 的支持期，如果他们愿意，MSFT 可以轻松更改它：)

编辑：
@DamianEdwards在线程中进一步写了这个：

.NET Framework 上对 ASP.NET Core 1.x 的支持将至少再延长一年（至 2019 年 7 月）。我们将每年重新评估这一点，并承诺在结束对 ASP.NET Core 1.x 的支持之前提供 12 个月的通知（因此，到 2018 年 7 月，我们将宣布我们是否会再延长 12 个月至 2020 年 7 月）（旁注：是我们已经在谈论 2020 年这一事实让其他人感到害怕吗？不？好吧，只有我。）

听起来不错。承诺再提供一年的支持，然后定期重新评估。对我来说完全有意义。

dustinmoris 于 2017-05-09

我已经阅读了这个线程中的每一篇文章。还有一个问题没有答案：为什么会做出这个决定？我只能得出结论，由于技术问题需要它。如果命名的“混乱”是问题，微软应该雇佣一个更好的公关人员，停止像团队在这个线程中所做的那样搅动狗屎。

那么在 netstandard2.0 上阻止 ASP.NET core 2.0 的技术问题是什么？在软件领域没有什么是不可能的，所以你不可能想出一个在 .NET full 上不可行的解决方案（因此不能包含在 netstandard20 中）。是的，这需要时间和精力，但我感觉你们都没有真正意识到这个决定对用户的副作用，他们因此需要投入多少时间/精力。

这个决定还有另一个缺点：ASP.NET Core 不是 netstandard 的消费者，因此不是它的驱动程序。它使 netstandard 成为追随者，因为 ASP.NET 核心不依赖它，所以没有什么意义：.net 核心 2.0+ 的 API 是面向目标的表面，因为 ASP.NET 核心针对的是该表面，而不是网络标准2.0。

而且，对不起@davidfowl ，我知道你的意思很好，但是一遍又一遍地向人们建议 ASP.NET core 1.x 表明你真的不知道你建议的人的情况是什么：人们无法迁移到 ASP.NET core 1.x，因为他们不知道在没有确定截止日期的情况下是否有一条顺利的道路：他们可能需要在该平台上停留的时间比他们目前认为的要长（需要移植依赖项等等。）。仅此一项就做出了迁移到 ASP.NET core 1.xa 的决定，这完全是基于 Microsoft 的“承诺”。这是一个用于面向互联网的代码的 API。他们需要知道他们是否可以在 3 年内运行今天构建的应用程序，因为微软将修复其中的安全漏洞（举个例子）。

坦率地说，我没有在 .NET 生态系统中启动另一个混乱集群的冲动：我们需要稳定性、可靠性和可靠性：“我今天编写的代码将在 5 年内按原样运行”。是的，我知道这对某些人来说听起来很傻，但这就是现实：这个星球上的软件包已经比维护它们的开发人员还多，而且差距只会越来越大。您不能简单地假设一个组织将决定使用 ASP.NET Core 作为他们的 webstack，并希望使用它编写的代码将在 5 年内运行，组织不再这样做：他们知道那里有堆栈可靠并给他们：他们知道他们可能无法在那个时间范围内重写整个应用程序，因此他们需要这种保证。

微软已经展示了这个线程，抱歉，他们在这个问题上的公关很糟糕，他们不能保证。而且，无论您在未来几天尝试在 \build 上给予多少旋转，我们在围栏的另一边已经了解到 Microsoft 营销！= 保证事情明天会奏效。

FransBouma 于 2017-05-09

👍15 👎4 ❤2

@FransBouma我不认为这是技术问题，听起来只针对netcoreapp2.0的动机是因为这是MSFT可以随心所欲地移动的唯一轨道，这对我们之后有好处全部，因为这意味着 ASP.NET Core 2.x 可以比以前 .NET 世界中的任何其他 Web 堆栈移动得更快。如果你不能接受这个快速训练，那么你可以在 ASP.NET Core 1.x 上停留更长时间（目前支持到 2019 年）

dustinmoris 于 2017-05-09

👍3

@FransBouma正如@davidfowl和@shanselman提到的，在.NET Core 中快速添加了新的API，ASP.NET Core 2.x 将使用其中的一些，因此希望以netcoreapp20 为目标。如果他们要将这些 API 添加到 netstandard2x，那么 .NET Framework 和其他平台将不得不迎头赶上，而且众所周知，它们的移动速度很慢。

alexwiese 于 2017-05-09

👍2

我将在辩论的“这是一件好事”这一方面加入我的声音。原因如下：

团队这样做不仅仅是为了地狱。 .NET Core 中已准备好（或几乎准备好）推出大量新功能和优化，这对于构建现代 Web 应用程序、API 和微服务并等待这些功能在完整的 Windows .NET 框架中落地的人们非常有用将延迟发布数月。
我在这个帖子中看到的许多抱怨都是“我不能在 .NET Core 2.0 中做 X”的一些变体，而作者的实际意思是“我必须改变我在 .NET Core 2.0 中做 X 的方式” _。是的，你必须改变。不，这不是一件坏事。如果您的 ASP.NET MVC 应用程序中有一小部分独立的功能可以处理 PDF 或 DOCX 文件，并且您_真的_找不到更好的方法来做任何事情（您尝试过吗？），然后打破它功能到在 Windows Server 上的完整 .NET 上运行的微服务中，并将其作为 HTTP API 从您的 .NET Core 应用程序中调用。分解应用程序并将特定功能移动到小型、独立的服务中甚至不是一种解决方法，_它是一种通用的最佳实践。_
- 注意据我所知，OpenXML 包现在支持 .NET Standard，因此使用 Word/Excel/其他任何东西都不是不可能的。
.NET Core 2.0 甚至还没有正式的公共预览版，所以抱怨它没有得到对 LDAP 的支持或任何似乎为时过早的东西。如果 RTM 在第三季度出现，但仍然无法与 AD 或 Kerberos 或其他任何东西交互，那么请抱怨（尽管也考虑迁移到基于令牌的现代身份验证系统，因为它不再是 2008 年了）。
_is_ 从 ASP.NET MVC 4.5 到 ASP.NET Core 2.0 的平滑迁移。它被称为 ASP.NET Core 1.0（我同意在这种情况下应该有长期支持 1.0 的承诺）。您可以使用 1.0 构建应用程序并在 Windows Server 2012 R2 上的 IIS 8.5 下的集成管道中的完整 .NET 上运行它们，直到
- 完整的 .NET 迎头赶上，您可以在其上运行 ASP.NET Core 2.x，或者
- 您依赖的任何第三方技术都支持 .NET Core（或者可以被支持 .NET Core 的等效技术替换）。
请记住，尽管您的团队可能会受到外部依赖或内部公司政策或政治或仅仅是惯性的束缚，但世界上有数十万（如果不是数百万）开发人员正在寻求使用现代构建应用程序、服务和 API架构模式和新技术平台（云/边缘/物联网/等），ASP.NET Core 2.0 非常适合。他们希望它是快速的、可扩展的和跨平台的；这些东西对很多人来说都很重要。仅仅因为您的第 3 方控件供应商或开源项目尚未移植他们的代码，就要求 Microsoft 忽略这个快速扩张的市场，这是愚蠢的。

markrendle 于 2017-05-09

👍19 👎2 ❤1

@dustinmoris表示 netstandard 缺乏创建快速 webstack 的 API。如果是这样，我们都有更大的问题。

@alexwiese就像我说的那样，我阅读了完整的主题，因此也阅读了您所指的帖子。我知道他们在说什么，也能理解他们的观点，但做出的决定表明他们不知道他们的用户在用他们的东西做什么。多年来，我自己构建了一个产品，并且知道一段时间后你会到达一个你想要削减东西并更快移动的地步，而不是过时的旧东西。但是这样做会产生后果，我在过去 14 年中学到的一件事是，向后兼容性是软件产品可以拥有的最大功能之一：能够使用它并且“它只是工作”是软件产品的关键点很多人来决定你的平台。你可能认为它没有那么重要，这很好，但是那里有很多人看不到它，因为他们的现实不同。

并不是 asp.net core 团队不应该快速行动，而是他们在迁移到 asp.net core 1.x 时打破了许多人的假设。

FransBouma 于 2017-05-09

👍3

@FransBouma为什么你认为你比微软更清楚微软的用户对微软的东西做了什么？

markrendle 于 2017-05-09

👍2

@markrendle

团队这样做不仅仅是为了地狱。 .NET Core 中已准备好（或几乎准备好）推出大量新功能和优化，这对于构建现代 Web 应用程序、API 和微服务并等待这些功能在完整的 Windows .NET 框架中落地的人们非常有用将延迟发布数月。

那么，告诉我，为什么不将这些超级骗子 API 创建为 .net 标准 2.0 包并将它们发布到 nuget 上呢？

为什么你认为你比微软更清楚微软的用户对微软的东西做了什么？

哦，我不知道，通过阅读该线程中的帖子？

FransBouma 于 2017-05-09

👍5

@FransBouma

这表明 netstandard 缺乏创建快速 webstack 的 API。如果是这样，我们都有更大的问题。

我不认为 netstandard 缺少任何东西，因为 netstandard 只不过是需要由想要支持该标准的平台实现的功能列表。理论上，我们可以随心所欲地移动 netstandard，只需在规范中添加更多内容，但实际上并非所有平台都能赶上这些新规范。

所以问题是，ASP.NET Core 2.x 是否想要提交到 netstandard2.0（当前最高），然后知道它被那里定义的所有东西卡住了，还是只 ASP.NET Core 2.x提交到 netcoreapp2.x，它可能不仅仅是 netstandard2.0。一段时间后，我确信会再次出现更新的 netstandard（3.x？），它将赶上来自 netcoreapp 的新闪亮事物，但这需要更多时间，为什么所有 asp.net 框架都应该被削弱以减缓进展. 拥有一个真正快速移动的 ASP.NET Core 堆栈是一件好事，只要还有第二个可以为人们提供符合 netstandard 的更长期的支持。

dustinmoris 于 2017-05-09

@FransBouma哦，对不起，我没有意识到你的样本量这么大。 257 条评论对不喜欢这个决定的人有强烈的偏见？很难与之争论。

免责声明：我不是大数据方面的专家。

markrendle 于 2017-05-09

👎5 😄4

@davidfowl ：

在整个线程中，您将 System.DirectoryServices 称为核心内容之一。我假设您有一些依赖项，您认为这些依赖项需要很长时间才能移植或永远不会移植。如果 2.0 支持 .NET Framework，这些依赖项会在一年内迁移吗？

是的，我们还有其他事情。 System.Directory 服务是我指出的，因为即使是请求最高的命名空间也没有准备好。所有其他人的情况都更糟。 API 可移植性分析器甚至没有针对我们可以运行它的 VS 2017 进行更新。用于查看您是否可以移植的分析器尚未投资，我们已经放弃了支持。

哪个？

Razor pages 是一个巨大的页面，我已经多次提到它。

我对 stackoverflow.com 一无所知，但是否可以拆分（我不想说“微服务”）以便 ASP.NET Core 可以用于某些部分？

不，这真的不可能。我们不会通过 API 调用和在事物之间增加开销来在 18 毫秒内渲染。我很乐意随时了解架构，您会发现这并不是一条合理的路线。

NickCraver 于 2017-05-09

👍5

我以为我之前已经解释过了，但又是这样：

任何作为 netstandard 一部分的 API 都需要发展缓慢。事物可以构建在 netstandard 之上，并且可以在任何地方运行，这很好。当您需要一个新的 API 时，例如 http 客户端、SSL 流、Int、字符串、数组、LINQ 或 NET Standard 中存在的任何原语，必须创建一个新的 .NET Standard 版本并且实现需要同意他们将实施它。现在这不是世界末日，因为我们现在拥有它们中的大部分，mono、.NET Core、.NET Framework、UWP，但还有其他一些像 Unity（可能还有其他）。每个 .NET 垂直行业都有自己的时间框架和发布周期，它们都是各自独立的产品，不容忽视。

但是现在你明白了，当新的 API 上线时，就会创建一个新的 netstandard 版本。如果库想要使用这些新的 API，那么您将立即失去对所有平台的支持。您可以交叉编译并尝试填充，但这并不能适应所有更改。

希望这能让您了解将 API 引入 netstandard 的过程可能是什么样的。 @terrajobst会更好地了解计划是什么。

davidfowl 于 2017-05-09

👍11

@DamianEdwards和@shanselman Service Fabric 和单元测试怎么样？

在我们的例子中，我们有一个大型的微服务项目，其中包含许多 SF 应用程序，这些应用程序是核心项目，但使用 .Net Framework 4.5 到 4.6.（某些东西）。 SF 目前不支持 netcoreapp，因此我们不得不使用 .Net Framework，但由于我们不想落后，我们使用了 .Net Core 项目。

（另一个问题是）因为我们的服务是 .Net Framework 并且 MS Fakes 不适用于 netcoreapp，所以我们所有的单元测试都是正常的（或者我应该说是遗留的）.Net Framework 项目。几乎我们所有的库都在 netstandard 1.0 到 1.6 上。

我们的客户端应用再次使用 Xamarin Forms + UWP，并且我们设法使用了 netstandard，因此我们的库是兼容的。

这是否意味着我们被卡住了，无法升级到 .Net Core 2.0 和 netcoreapp2.0 以及 netstandard 2.0？

aboo 于 2017-05-09

@尼克克拉弗

Razor pages 是一个巨大的页面，我已经多次提到它。

我理解这一点，但我不敢相信您只会将所有堆栈溢出转换为剃刀页面。如果您现在已经在使用 MVC，为什么不直接移植到常规视图，当更多依赖项上线时，移植到剃刀页面。 Razor 页面的设计方式使得从控制器动作到 Razor 页面变得微不足道。

是的，我们还有其他事情。 System.Directory 服务是我指出的，因为即使是请求最高的命名空间也没有准备好。所有其他人的情况都更糟。 API 可移植性分析器甚至没有针对我们可以运行它的 VS 2017 进行更新。用于查看您是否可以移植的分析器尚未投资，我们已经放弃了支持。

只需确保升级该依赖项列表，以便我们知道什么是重要的。

davidfowl 于 2017-05-09

@aboo

这是否意味着我们被卡住了，无法升级到 .Net Core 2.0 和 netcoreapp2.0 以及 netstandard 2.0？

你的意思是 ASP.NET Core 2.0 和？ .NET Core 2.0 和 .NET Standard 2.0 在这里并不真正适用。

是的，您必须继续使用 ASP.NET Core 1.x。

davidfowl 于 2017-05-09

为使事物兼容而完成的大部分工作是在 .NET Core 2.0 和 .NET Standard 2.0 中完成的。 ASP.NET Core 2.0 确实没有那么多新功能。据说我们要将 SignalR 反向移植到 ASP.NET Core 1.x（无论如何都是 2.0 之后的版本）。它只是一个感知的东西吗？

@davidfowl我认为当你被告知你将不得不迁移东西时，你大大低估了 Windows 开发人员内心的恐惧。 _特别是_当新堆栈没有达到与旧堆栈的功能奇偶性时，并且不知道是否以及何时会发生这种情况。这基本上宣布了 ASP.NET Core 在完整的 .NET Framework 上的 EOL-ing。而且，虽然这可能不是长期计划，但它被宣布为一项功能，人们认为它可能会持续一段时间。正如我们所说，路线图正在发生变化。将举行会议。

由于名义上维护的数据库连接器和 SDK，我们必须支持一些令人作呕的旧东西。与维护现有产品相比，其中一些供应商更有可能发布具有 30% 现有功能、HTML5 界面和一系列新漏洞的新 API。或者他们可能只是收购竞争对手，发布产品并迅速停产。其中一些供应商大到足以被识别。我们有很多不错的代码，但尽管我们尽了最大努力，但其中一些代码也存在于 Windows 贫民窟中，因为它并不总是在我们的控制之下。老技术不只是优雅地退休。它潜伏在你的床底下、我们的壁橱里和你的键盘下面。

我更关心这一举动表明 .NET Standard 可能被边缘化，而不是其他方面。 .NET Standard 最初似乎可以使不同的实现越来越接近功能对等，同时允许消费者迁移到不断发展的、不断增长的平台。现在，它听起来不过是 .NET Core 功能的里程碑。您将无法（或不想）将可执行文件定位到 .NET Standard - 仅限库。听起来.NET Standard 中涉及的计划将大大减少，相反，它只会在 ASP.NET 中使用的任何东西上盖上橡皮图章，因为改变已经太迟了。毕竟，它已经投入生产了。

其他开发人员必须在代码中添加编译器指令，将代码拆分为特定于平台的库并使用多个目标进行编译。我粗鲁的部分希望 ASP.NET Core 团队对此进行测试，以便您对多目标和多平台场景的更好的运行时和工具支持感兴趣。如果您的团队想要它，那么我们可能会得到它。我的实际部分说，您至少应该定期发布针对 .NET Standard 的 ASP.NET Core。无论如何，您都需要制作实际的 _stable_ 版本。没有人会从 git 编译 master 分支并部署到生产环境。为什么不对 .NET 标准进行较小的迭代并将它们与标记的 ASP.NET 版本相匹配？

另外，桌面是否会有新的 ASP.NET？所有的宣传都让 ASP.NET Core 听起来像是唯一的 ASP.NET。现在听起来除非您使用 .NET Core，否则您不会在 ASP.NET 上获得任何新东西。这将改变很多商业策略。路线图存在很多混乱。

MVC 5 永远不会消失，我们不会弃用任何东西。只要 .NET Framework 存在，它就会受到支持。

是的，我们很清楚旧的东西会留在那里。它通常会这样做，我们对此表示赞赏。但新事物是否会出现在“完整”框架上非常重要。我们需要知道事情的发展方向。我们不想坐火车到最后才想着怎么往前走。我们也让我们的乘客担心。 .NET Core 和 .NET Framework 之间的差异让很多人对未来充满不确定性。一年半前，我问了一个问题，即 .NET Core 何时支持特定功能部分。我什至问如果我要亲自处理它是否会被接受。交流一直很稀少。我仍然不知道会发生什么。这种关于支持的场景和时间线的不确定性对我们编写的代码产生了巨大的影响。即使知道桌面框架的哪些部分是低优先级的，也可以让人们有足够的时间进行迁移，而不是等待状态更新。

简而言之，我支持你正在做的事情以及它背后的目标。而且我知道，当我们站到这里并抱怨您出于非常充分的理由做出的决定时，这很难。但是很多人不会跳上先锋列车，因为他们不能，而其他人不会，因为他们不知道它的去向。

ZigMeowNyan 于 2017-05-09

👍5

@davidfowl我猜。您如何称呼 .Net Framework 的核心项目（新）？不管是什么，我从帖子中的理解是 netstandard vNext 不会支持它。

aboo 于 2017-05-09

@markrendle我们是真正的客户。我们告诉人们事情是行不通的。我比你更了解我的架构，所以傲慢的评论没有帮助。你的观点：

团队这样做不仅仅是为了地狱。 .NET Core 中已准备好（或几乎准备好）推出大量新功能和优化，这对于构建现代 Web 应用程序、API 和微服务并等待这些功能在完整的 Windows .NET 框架中落地的人们非常有用将延迟发布数月。

没有人反对他们也支持这些事情。我们的抱怨普遍是关于放弃支持，而不是有条件地添加新功能。

我在这个帖子中看到的许多抱怨都是“我不能在 .NET Core 2.0 中做 X”的变体，而作者的实际意思是“我必须改变我在 .NET Core 2.0 中做 X 的方式”。是的，你必须改变。不，这不是一件坏事。如果您的 ASP.NET MVC 应用程序中有一小部分离散功能可以处理 PDF 或 DOCX 文件，并且您真的找不到更好的方法来做任何事情（您尝试过吗？），然后打破它功能到在 Windows Server 上的完整 .NET 上运行的微服务中，并从您的 .NET Core 应用程序中将其作为 HTTP API 调用。分解应用程序并将特定功能移动到小型、独立的服务中甚至不是一种解决方法，而是一种通用的最佳实践。

这离基地太远了，我不知道从哪里开始。在“微服务”中，我们的页面会慢得多，成本也会高得多。使用这种设置，我们在 GC 中花费的时间要比在页面渲染中花费的时间要多得多。这也假设完整的框架依赖不是每个页面渲染的关键部分。不好的假设。

.NET Core 2.0 甚至还没有正式的公共预览版，所以抱怨它没有得到对 LDAP 的支持或任何似乎为时过早的东西。如果 RTM 在第三季度出现，但仍然无法与 AD 或 Kerberos 或其他任何东西交互，那么请抱怨（尽管也考虑迁移到基于令牌的现代身份验证系统，因为它不再是 2008 年了）。

我们被告知他们不会在那里。观看站立。或者查看标有“Future”的 GitHub。我们现在正在抱怨，因为这个糟糕的决定将在第三季度发布。

从 ASP.NET MVC 4.5 顺利迁移到 ASP.NET Core 2.0。它被称为 ASP.NET Core 1.0（我同意在这种情况下应该有长期支持 1.0 的承诺）。

长期支持并不意味着它不是死胡同。当 1.x 生命周期结束时，我们仍然很容易被困在它上面。在这种情况下，我们对完整框架的支持会更长。

完整的 .NET 迎头赶上，您可以在其上运行 ASP.NET Core 2.x

它的目标是netcoreapp ，这不会发生。

...或您依赖的任何第三方技术都支持 .NET Core（或者可以被支持 .NET Core 的等效技术替换）。

这些图书馆通常超出人们的控制和时间预算。 甚至微软的库也没有升级。我现在正在与 SQL 团队战斗，以升级他们的包以在新项目系统上工作，因为 install.ps1 有效。如果我们甚至无法获得这些简单的修复，我们就会被netstandard端口搞砸了。

请记住，尽管您的团队可能会受到外部依赖或内部公司政策或政治或仅仅是惯性的束缚，但世界上有数十万（如果不是数百万）开发人员正在寻求使用现代构建应用程序、服务和 API架构模式和新技术平台（云/边缘/物联网/等），ASP.NET Core 2.0 非常适合。他们希望它是快速的、可扩展的和跨平台的；这些东西对很多人来说都很重要。仅仅因为您的第 3 方控件供应商或开源项目尚未移植他们的代码，就要求 Microsoft 忽略这个快速扩张的市场，这是愚蠢的。

称其为愚蠢是轻视、粗鲁和不必要的。这就是我们的生活。这些是我们的应用程序。这些是我们花了数年或数十年创造的东西，在发布之前我们突然发现前景对我们来说是有时间上限的，很难。至少可以说引入了很多不确定性。在你的职业生涯中，这并不是你真正想要的。

NickCraver 于 2017-05-09

👍61

每一点都有道理，但请记住，在这个宇宙中，一切都会处于需要较少能量的状态，然后确保那个状态是你想要去的地方，因为我们会以某种方式去那里。
因此，如果您想达到某种状态，请确保它所需的能量比保持我们现在所在位置所需的能量少。

Duke360 于 2017-05-09

在有人在 IRC 中提到这一点后，我刚刚通读了整个线程——我还没有看到任何官方声明——我非常失望。

我一直在关注 .NET Core，参与并将小型项目从 .NET Framework 转换为 .NET Standard / .NET Core，以便获得一些使用新 SDK 和运行时的经验，并在 macOS 和 Linux 上运行这些项目.

我的主要目标是使用大量组件的大型企业 Web 服务，这些组件 [尚未] 在 .NET Core 1.0 或 1.1 中可用。这包括，就在我的脑海中：

Active Directory ( System.DirectoryServices )，用于身份验证和用户管理
Entity Framework 6 ( EntityFramework )，因为 EF Core 还不支持我们使用的很多功能。
OData ( Microsoft.Data.Services / System.Data.Services ) v1-3，我们使用的客户端 Javascript 库（目前）还不支持 v4，而且 WebAPI OData 的设置要复杂得多。
IIS 管理 ( System.Web.Management ) 和 .NET Remoting ( System.Runtime.Remoting ) 用于 Web 服务自身升级的能力——尽管这可以提取到一个独立的应用程序中。
信号R
自定义IHttpHandler s 和IHttpModule s，必须适应任何 ASP.NET Core 的等价物，可能是某种中间件
一大堆使用 ASP.NET WebAPI 的可扩展性的自定义东西。
我想我们甚至可以在服务器上使用Microsoft.TeamFoundationServer.ExtendedClient ，它只支持 net46，有一些本地程序集，并且在 .NET Core 2.0 上工作的可能性大约为 0%。
等等。

由于这项服务的规模和复杂性，任何向 .NET Core 的迁移都必须是循序渐进的，而且很可能我们可能不得不使用一些新的 ASP.NET-Core-2.0 API，我不知道然而，我们还没有走到那一步。

删除在 .NET Framework 上运行 ASP.NET Core 的能力意味着如果 ASP.NET Core 1.x 不是可行的垫脚石，则必须以大爆炸式的方式进行迁移。在“在新运行时运行新框架”之前，我们立即失去了“在旧运行时运行新框架”的阶段。对于任何大型系统来说，这都是一种可怕的变更管理策略。

如果 .NET Core 达到或接近同等水平时放弃 .NET Framework 支持，我不会太介意，但对于任何足够高级的应用程序来说，它仍然远远落后，而且我认为 2.0 不适合做这样的事情一个突破性的变化。

yaakov-h 于 2017-05-09

👍2

@davidfowl

我理解这一点，但我不敢相信您只会将所有堆栈溢出转换为剃刀页面。如果您现在已经在使用 MVC，为什么不直接移植到常规视图，当更多依赖项上线时，移植到剃刀页面。 Razor 页面的设计方式使得从控制器动作到 Razor 页面变得微不足道。

许多跨应用程序共享的库等都在这里发挥作用。 Stack Overflow 有很多应用程序（主网站几乎完全是一个应用程序，但作为一家公司：我们有很多相关的、交流的东西。

只需确保升级该依赖项列表，以便我们知道什么是重要的。

是的，我正在这样做。但这不会是最后一个依赖，只是最大的障碍，因为没有它我们甚至无法登录某些应用程序。这是第一个屏幕断路器。本周我将尝试在我们的应用程序中执行完整的可移植性分析器（在今天早上发布之后），但我担心它会更加令人沮丧。如果在考虑这样的动作之前甚至针对当前工具更新分析器，这将有所帮助。

数据有帮助，我会尝试获取更多数据——除非这个决定改变的可能性为零。如果是这种情况，请告诉我们，这样我就不会再花时间在这上面了。

NickCraver 于 2017-05-09

仅作记录：OData 是另一个尚不支持 netcoreapp 的库。

实际上它甚至仍然基于 System.Web（您必须通过 ASP.NET Core 中的 OWIN 中间件使用它）并且他们承诺支持（参见 https://github.com/OData/WebApi/issues/939）。

还是值得一提的。特别是因为它来自微软。

编辑：@yaakov-h 快了 2 分钟，所以 +1 提到了 OData

froitag 于 2017-05-09

我仍然在这里回复有几个原因

我在乎
睡眠是给弱者的😆
我需要打电话给 FUD，因为互联网上有人错了

davidfowl 于 2017-05-09

❤24 👍6

@尼克克拉弗

许多跨应用程序共享的库等都在这里发挥作用。 Stack Overflow 有很多应用程序（主网站几乎完全是一个应用程序，但作为一家公司：我们有很多相关的、交流的东西。

这只是意味着你不能使用 Razor pages tbh，ASP.NET Core 2.0 有很多小东西，但没有大的功能或修复也没有被移植到 1.x。 EOL 的事情是非常真实的，我个人认为 ASP.NET Core 2.0 再支持 .NET Framework 一年不会有帮助。我们真的在这里讨论了一个方向的改变，要么我们永远支持.NET Framework，要么不，真的没有中间。

davidfowl 于 2017-05-09

👍1

@dustinmoris不仅如此。也是一个期望问题。您的用例可能与其他所有人不同。

我正在开发 aspnetcore 1.* 应用程序并使用 .NET 桌面作为运行时（企业的 LOB）。

而且我了解.net核心运行时，netstandard等之间的区别（只是为了确保这不是关于对此误解的评论）

我的迁移是首先到 aspnet 核心（针对 .net 桌面），因为流程/视觉/等，合并它，然后将其移动到 .net 核心（如果可能），是 aspnetcore 选择的决定性场景。

这个问题有点出乎意料，因为 aspnetcore 1.* 一直被宣传为“在两个框架上运行”，关于下一个（版本或年份）放弃它的零警告 afaik。
我期待一个过时的 -> 至少已弃用的周期，或者只是不支持的功能（没关系）。

.net（以及作为 Web 堆栈选择的 aspnet）的好处是我可以利用现有的代码库和库。
当目标（.net core/netstandard）过于流动时，有些是内部的，没有真正的投资回报率来迁移这些。
有些是外部的，很难更改，如果这些在 netcoreapp2 闭包中不起作用，我将无法使用这些。

另外，我的想法是巩固netstandard2而不是netcoreapp2 。
如果还没有，我该如何开始评估库到 netstandard2 的迁移？很难根据预览位和承诺评估迁移（最近几年降低了我对承诺稳定性的信任）

我知道这是与完全绿地不同的场景，但如果绿地我想重用一些库，因为我需要与现有系统（excel/pdf/etc）交互，而不是从零开始重写所有内容。
或者仅仅因为最新趋势而将微服务添加为 rpc，因为使事情变得更加复杂（这是我想要评估和执行的明智选择，而不是被迫包装现有的库）。我需要交付价值（aspnetcore 开发流程很好且富有成效），而不仅仅是改变架构。

在我对生态系统的个人评估中，对于我的用例，.net core 和/或 netstandard lib 的可用性太低（不是每个人都只使用免费的 nuget.org oss pkgs）。因此，如果我需要努力迁移到新堆栈，我还需要评估其他堆栈（成本/收益/未来/信任/等）

我不仅在编写一个 TODO Web 应用程序，我还使用 .NET，因为我已经准备好多年的东西，所以我可以改变一件事（在本例中为 aspnetcore，其余部分保持不变）。
在我的场景中，只要改变一切都是灾难的根源，当我需要这样做时，我需要真正开始评估迁移到 lib 存在的另一个堆栈（如 java/node）是否更有意义。

顺利迁移需要时间，我喜欢未来 aspnet 核心的愿景。但如果我没有明确的路径（或对此表示怀疑），则很难在内部进行销售。

也就是说，留下 .net 桌面，对于 aspnet 团队来说可能是一场很好的赌博，可以更快地移动并挑选更多新用户（或者不要失去对 node/java 的电流）。
但可以肯定的是，这将使开发人员在较慢的环上的生活更加艰难，这是 aspnet 团队的电话（他们的产品）。
我的反馈是不要那样做，并努力支持 fw，因为作为开发人员，我需要信任和稳定性，而去年 .net 生态系统（不仅仅是 netcore/project.json，但之前此外，市场营销/传道者也没有帮助降低信任）

enricosada 于 2017-05-09

@yaakov-h

如果您决定移植到 ASP.NET Core（1.x 或 2.x），您将需要另一个进程。 ASP.NET Core 不在 System.Web 上运行，因此您无法在同一个项目中进行渐进式移植。

如果 .NET Core 达到或接近同等水平时放弃 .NET Framework 支持，我不会太介意，但对于任何足够高级的应用程序来说，它仍然远远落后，而且我认为 2.0 不适合做这样的事情一个突破性的变化。

没有合适的时间放弃它。它从未打算与 .NET Framework 达到同等水平，而且很可能存在永远不会移植的依赖项。鉴于此，我的问题是，您是重新设计应用程序还是真的需要永远使用 .NET Framework？

davidfowl 于 2017-05-09

@davidfowl完全取决于我们的上游依赖项。在这个时间点上，我们将永远停留在 .NET Framework 上。

有趣的是，大多数第 3 方已经有netstandard版本可用。主要是 Microsoft 依赖项使我们保持在 .NET Framework 上，其中一些似乎已被半放弃（例如 OData）

yaakov-h 于 2017-05-09

👍5 😄3

@NickCraver我并不是要贬低或侮辱。我很欣赏这是一个较晚的变化，这对于社区中受它影响的任何部分来说都是令人沮丧的，如果我受到它的影响，我可能也会大惊小怪。我不是（在我工作的地方，我们仍然使用 ASP.NET WebAPI 5.2.3），所以我对这种情况的看法不那么情绪化。

以这种方式看待它：如果您今天从头开始构建下一个 Stack Exchange（无论可能是什么），ASP.NET Core 团队想要使用的netcoreapp20中的东西（像 UTF8Strings 和 Pipelines 以及低分配、异步、_fast_ 原语（我猜有一点））让它比完整的 .NET 更吸引你？ .NET Core 2.0 通常不会比完整的 .NET 4.7.1 更有意义吗？如果您要在可以快速发展和适应变化的 Web 堆栈与不可撤销地与缓慢移动的底层技术绑定的 Web 堆栈之间进行选择，并且需要担心支持近 20 年的遗留代码，您会选择哪一个？

markrendle 于 2017-05-09

👍3

@ZigMeowNyan

我更关心这一举动表明 .NET Standard 可能被边缘化，而不是其他方面。 .NET Standard 最初似乎可以使不同的实现越来越接近功能对等，同时允许消费者迁移到不断发展的、不断增长的平台。现在，它听起来不过是 .NET Core 功能的里程碑。您将无法（或不想）将可执行文件定位到 .NET Standard - 仅限库。听起来.NET Standard 中涉及的计划将大大减少，相反，它只会在 ASP.NET 中使用的任何东西上盖上橡皮图章，因为改变已经太迟了。毕竟，它已经投入生产了。

这些实际上是非常好的观点，值得考虑。您必须了解，它与 .NET Standard 被搁置无关，它只是物理学。如果每个 .NET 平台都按照自己的节奏移动，那么使用最新的 .NET 标准意味着移动速度较慢的框架得到的东西更少。这是每个人都应该内化的东西。这并没有减少它的用处，这只是野兽的本性。消除这种负担的唯一方法是有一个单一的实现和一个单一的船计划，这大大缩小了 .NET 能够运行的地方。

其他开发人员必须在代码中添加编译器指令，将代码拆分为特定于平台的库并使用多个目标进行编译。我粗鲁的部分希望 ASP.NET Core 团队对此进行测试，以便您对多目标和多平台场景的更好的运行时和工具支持感兴趣。如果您的团队想要它，那么我们可能会得到它。我的实际部分说，您至少应该定期发布针对 .NET Standard 的 ASP.NET Core。无论如何，您都需要制作实际的稳定版本。没有人会从 git 编译 master 分支并部署到生产环境。为什么不对 .NET 标准进行较小的迭代并将它们与标记的 ASP.NET 版本相匹配？

我们做同样的事情，记住，我们仍然针对我们的一堆库和那些确实包含 ifdefs 的 netstandard。然而，其他人则以 netstandard 为目标，以便为我们在 2.x 时间范围内利用新 API 做好准备。

简而言之，我支持你正在做的事情以及它背后的目标。而且我知道，当我们站到这里并抱怨您出于非常充分的理由做出的决定时，这很难。但是很多人不会跳上先锋列车，因为他们不能，而其他人不会，因为他们不知道它的去向。

诚实的问题（这是我问的不是微软），你更喜欢兼容性而不是新功能吗？如果是，为什么选择 ASP.NET Core？

davidfowl 于 2017-05-09

👍3

另一个快速的想法：对于像这样的每个线程，都存在一个等效但相反的线程，其中一个不同但同样大的群体因为对支持“旧”.NET 做出让步而感到沮丧。

markrendle 于 2017-05-09

👍4

有趣的是，大多数第 3 方已经提供了 netstandard 版本。主要是 Microsoft 依赖项使我们保持在 .NET Framework 上，其中一些似乎已被半放弃（例如 OData）

😞

davidfowl 于 2017-05-09

😄6 ❤3

@markrendle

• 我在这个帖子中看到的许多抱怨都是“我不能在 .NET Core 2.0 中做 X”的变体，而作者的实际意思是“我必须改变我在 .NET Core 2.0 中做 X 的方式” . 是的，你必须改变。不，这不是一件坏事。如果您的 ASP.NET MVC 应用程序中有一小部分离散功能可以处理 PDF 或 DOCX 文件，并且您真的找不到更好的方法来做任何事情（您尝试过吗？），然后打破它功能到在 Windows Server 上的完整 .NET 上运行的微服务中，并从您的 .NET Core 应用程序中将其作为 HTTP API 调用。分解应用程序并将特定功能移动到小型、独立的服务中甚至不是一种解决方法，而是一种通用的最佳实践。
注意据我所知，OpenXML 包现在支持 .NET Standard，因此使用 Word/Excel/其他任何东西都不是不可能的。<<

正如其他人已经说过的，改变我们漂亮设计的架构并不是一个好计划。在我们的例子中，我们在应用程序的 WPF 测试和服务器之间共享代码。我们在那些更复杂的人之间创造的差异越多，维护就越复杂。

我可以向您保证，我已经花了很多时间研究最适合我们用于 PDF、DocX 生成的工具，而且它远没有使用开放 XML 那么简单。我们使用第三方库，因为他们已经开发了数万行代码，我们不必开发/维护/测试。这就是重点。

.net 版本控制变得非常复杂。我不清楚将来 ASP.net 是否可以在完整的 .net 框架上使用？因为我需要在服务器和我的桌面应用程序之间共享代码，这是否意味着我永远无法拥有最新版本的 ASP.Net？这在短期内不是问题，但从长远来看，随着安全性改进等等，我不想离最新版本太远。我确信在我的船上还有很多其他人需要与完整框架进行某种形式的兼容性。

为了澄清我所做的是，我拥有三个我自己的库，它们在各种 WPF 应用程序和我的服务器之间共享。在这一点上，我完全不知道我使用的哪个 API 可能在.net 核心中可用，也可能不可用。然后在这些库中，我使用 Telerik 和 SyncFusion 的 WPF 工具的完整桌面版本来生成 docx 和 pdf。这些工具使用的部分或全部功能可能在 .net 核心中可用，也可能不可用。尝试基于可能或可能不开发应用程序是极其困难的。微软在 .net 中有一个出色的基础框架，虽然我理解 .net 核心背后的原因。微软似乎忘记了向后兼容的重要性。

斯特凡

stefanolson 于 2017-05-09

@markrendle

哦，对不起，我没有意识到你的样本量这么大。 257 条评论对不喜欢这个决定的人有强烈的偏见？很难与之争论。免责声明：我不是大数据方面的专家。

不知道我对你做了什么，但没有必要像这样狡猾或低级的抱怨。你很清楚这个线程只是一个例子。

FransBouma 于 2017-05-09

👍3

@stefanolson

.net 版本控制变得非常复杂

我认为这是我们都可以同意的少数几件事之一。

我们正在寻求移植到 .Net Core x。
我们最大的问题是：
NewRelic （没有 .Net Core 计划，所以我们需要找到一个替代方案）
NH （EF Core 没有这些功能）。
ServiceBase （听起来它会在夏天出现在 .Net Core 2 中）

听起来我们必须在过渡期间以 Core 1.0 为目标，等待 NH、EF 升级或发挥创意。

penderi 于 2017-05-09

👍3

这只是意味着你不能使用 Razor pages tbh，ASP.NET Core 2.0 有很多小东西，但没有大的功能或修复也没有被移植到 1.x。 EOL 的事情是非常真实的，我个人认为 ASP.NET Core 2.0 再支持 .NET Framework 一年不会有帮助。我们真的在这里讨论了一个方向的改变，要么我们永远支持.NET Framework，要么不，真的没有中间。

它比 Razor 页面大一点，这意味着没有理由移动。不存在这两种情况都存在的（当前）场景：

我们会一直得到支持
另一边有一个实际的升级

事实上，如果没有生态系统，ASP.NET Core 并没有那么有用。拥有一个可以返回文本的控制器很棒，但对于很多场景来说没有用。我们需要 API。我们需要图书馆。我们需要生态系统，这就是我们首先选择 .NET 的原因。

这种变化来自于一个完全支持我们今天的用例的框架，而这个框架显然还没有准备好。它甚至还没有准备好。测试它是否准备就绪的预览甚至不普遍可用。无法进行迁移以找出准备就绪的承诺。我们寄希望于一大堆承诺，许多承诺会被烧毁。这是推销这些东西的最糟糕的方式：过度承诺和过度交付（整体体验）。

我认为 ASP.NET Core 很棒。你们正在做很棒的事情。我很幸运能够帮助解决其中的一些问题。但是这个时间点的转换是不好的。如果我们认为将要移植的所有东西实际上都在 2.x 时间范围内移植，那就太好了。然后在 3.x 中进行更改。在替代品准备好之前移植并为何时终止 EOL 生命线设定最后期限是不好的。告诉人们移植到维护 -> EOL 版本是不好的。

请不要现在进行此更改。 .NET 比这更好。表明您关心您的用户，就像这里的每个人都关心您一样。如果我们不想帮忙，我们就不会在这里。

NickCraver 于 2017-05-09

👍27

@FransBouma你（应该）非常清楚，微软拥有庞大的遥测、反馈和其他数据数据库，这些数据库包含人们使用他们的技术所做的事情，这些数据比任何数量的 GitHub 问题线程都提供了更清晰的画面，我不认为我的指出这一点比

哦，我不知道，通过阅读该线程中的帖子？

markrendle 于 2017-05-09

👎1 👍1

.net 版本控制变得非常复杂。我不清楚将来 ASP.net 是否可以在完整的 .net 框架上使用？因为我需要在服务器和我的桌面应用程序之间共享代码，这是否意味着我永远无法拥有最新版本的 ASP.Net？这在短期内不是问题，但从长远来看，随着安全性改进等等，我不想离最新版本太远。我确信在我的船上还有很多其他人需要与完整框架进行某种形式的兼容性。

跨不同 .NET 运行时的代码共享故事是 .NET Standard。您的库应尝试将其定位为跨 .NET Core 和 .NET Framework 共享的代码。

微软似乎忘记了向后兼容的重要性。

问题是，ASP.NET Core 从来都不是向后兼容的……这就是为什么从 ASP.NET 4.x 出现如此大的范式转变的原因。似乎向后兼容性是您最好在 .NET Framework 上使用 ASP.NET 4.x 的高阶位。这在可预见的未来是受支持的，只要 Windows 还活着，就会得到安全补丁。

davidfowl 于 2017-05-09

即使不是这样，1.0 也是非常向后兼容的！它支持了整个生态系统的巨大遗产，我们对此表示赞赏。当时似乎没有人必须放弃他们的蛋糕或不吃它。

gulbanana 于 2017-05-09

👍1

@尼克克拉弗

它比 Razor 页面大一点，这意味着没有理由移动。不存在这两种情况都存在的（当前）场景：

你能详细说明吗？

事实上，如果没有生态系统，ASP.NET Core 并没有那么有用。拥有一个可以返回文本的控制器很棒，但对于很多场景来说没有用。

它也可以做得非常快😉

我认为 ASP.NET Core 很棒。你们正在做很棒的事情。我很幸运能够帮助解决其中的一些问题。但是这个时间点的转换是不好的。如果我们认为将要移植的所有东西实际上都在 2.x 时间范围内移植，那就太好了。然后在 3.x 中进行更改。在替代品准备好之前移植并为何时终止 EOL 生命线设定最后期限是不好的。告诉人们移植到维护 -> EOL 版本是不好的。

我不明白为什么 2.x (support) 和 3.x (drop) 比 1.x (support) 和 2.x (drop) 好。你能给我解释一下吗？这有什么区别？

davidfowl 于 2017-05-09

为那些关心长期支持 ASP.NET 变体的人提供了一些 //BUILD 2017 会话建议：

T6009 ASP.NET Web 窗体更新
- 即他们仍在开发完整的 .NET Web 平台
T6072 对 ASP.NET Core 的支持：什么是 LTS？
- 我猜现在正在疯狂更新：做鬼脸：

markrendle 于 2017-05-09

@davidfowl ：

这有什么区别？

因为您已经承诺在 2.0之后发布一些最重要的缺失 API？

yaakov-h 于 2017-05-09

@yaakov-h

因为您已经承诺在 2.0 之后发布一些最重要的缺失 API？

告诉我 ASP.NET Core 中有哪些？

davidfowl 于 2017-05-09

@davidfowl System.DirectoryServices, System.Drawing 上面提到过。

yaakov-h 于 2017-05-09

诚实的问题（这是我问的不是微软），你更喜欢稳定性和兼容性而不是新功能吗？如果是，为什么选择 ASP.NET Core？

我认为这是一个非常好的问题。如果完整的 .NET 框架提供了他们今天所需的一切，那么为什么如此热衷于迁移到完全不同的堆栈呢？如果 .NET Core 和 ASP.NET Core 的名称不同，而没有 .NET int 名称，那么我认为很少有人会争论迁移问题。没有人抱怨他们无法迁移到移动速度更快的 Go 或 Node.js Web 堆栈。

dustinmoris 于 2017-05-09

@davidfowl向后兼容 ASP.NET MVC 5.x 是一回事，向后兼容 .net 框架是另一回事。放弃 .net 框架是一件大事......

我不明白为什么 2.x (support) 和 3.x (drop) 比 1.x (support) 和 2.x (drop) 好。

因为据我们了解，2.x 很快就会到来。

hikalkan 于 2017-05-09

@davidfowl System.DirectoryServices, System.Drawing 上面提到过。

这些与 ASP.NET Core 1.x 或 2.x 无关，并且在它们上线时将在两者上运行。

就像我说的，我来这里只是为了喊出 FUD，这就是其中的一部分。这个线程已经变得如此之大，以至于没有人可以在某些回复中看到事实。

davidfowl 于 2017-05-09

👍2

@FransBouma你（应该）非常清楚，微软拥有庞大的遥测、反馈和其他数据数据库，这些数据库包含人们使用他们的技术所做的事情，这些数据比任何数量的 GitHub 问题线程都提供了更清晰的画面，我不认为我的指出这一点比

@markrendle遥测并不神奇。你无法衡量为什么 ppl/dev 没有切换，或者他们为什么切换到其他堆栈，或者他们的项目的重要性以及他们有多喜欢堆栈（并通过咨询或 oss 帮助他人），或者他们在做什么。

这个线程正是如此，一个反馈。

我不明白为什么 2.x (support) 和 3.x (drop) 比 1.x (support) 和 2.x (drop) 好。你能给我解释一下吗？这有什么区别？

@davidfowl时间。
是时候安顿一下了。是时候评估事情了。是时候一次改变一件事了。是时候将netstandard2包与 rtm 一起使用了。是时候将我们的库移动到 netstandard2（更容易）而不是 netstandard1（更难）了。是时候一次改变一件东西了，对我来说，主要是。
你做 aspnet，但我的产品不仅仅是 aspnet，它是许多库、权衡和生态系统的组合。

enricosada 于 2017-05-09

因为据我们了解，2.x 很快就会到来。

这与它有什么关系？如果 2.0 在年底或 1 月到来怎么办？它会有所作为吗？是什么在 2.0 中使 1.x 不值得？

davidfowl 于 2017-05-09

@yaakov-h 在@shanselman所说的地方提到了他们（强调我的）

AD – 完全是，如果您想直接调用 LDAP，这是一个差距。您现在当然可以针对 Windows Auth 进行身份验证。我们计划在夏季时间框架内专门为 Core 2.0 提供DirectoryServices 命名空间
绘图 - 完全，这是一个差距。我们计划在夏季时间框架内为 Core 2.0提供此功能。在此之前，这些 netstandard 选项还存在 ImageSharp、ImageResizer、Mono 选项等

markrendle 于 2017-05-09

@davidfowl这不是关于版本，而是关于 .net 核心及其生态系统的日期和成熟度。

hikalkan 于 2017-05-09

@hikalkan

对不起，我从非常高水平的 POV 中理解这一点，但不是从技术角度。也许这不是技术讨论？

davidfowl 于 2017-05-09

👍1

@enricosada

是时候安顿一下了。是时候评估事情了。是时候一次改变一件事了。是时候使用带有 rtm 的 netstandard2 包了。是时候将我们的库移动到 netstandard2（更容易）而不是 netstandard1（更难）了。是时候一次改变一件东西了，对我来说，主要是。
你做 aspnet，但我的产品不仅仅是 aspnet，它是许多库、权衡和生态系统的组合。

为什么这对 ASP.NET Core 2.0 有特别的影响？无论 ASP.NET Core 选择做什么，您都将从该平台中获益。

davidfowl 于 2017-05-09

@markrendle有人给我一个日历，因为季节跨越了整个季度（可能比同一季度的其他时间晚 3 个月），这对我们南半球的人来说尤其令人困惑。

yaakov-h 于 2017-05-09

@enricosada您可以从遥测和其他数据源（网络分析、搜索数据、直接客户反馈）中获得大量有用的信息。远远超过你从 GitHub 上愤怒的暴徒那里得到的东西（但是每个人的愤怒可能是合理的）。

markrendle 于 2017-05-09

👍1

@yaakov-h 嗯，.NET Core 2.0（以及 ASP.NET Core 2.0）当前预计的 RTM 是日历 Q3，也就是 7 月/8 月/9 月），而北半球的夏季主要是 7 月/8 月/9 月，所以基本上是一样的。

markrendle 于 2017-05-09

您可以从遥测和其他数据源（网络分析、搜索数据、直接客户反馈）中获得大量有用的信息。

不过，我想知道这种遥测技术（至少是自动化部分）对于企业部署有多可靠。（因为这似乎是大部分反弹的来源。）

dahauns 于 2017-05-09

我不明白为什么 2.x (support) 和 3.x (drop) 比 1.x (support) 和 2.x (drop) 好。你能给我解释一下吗？这有什么区别？

@davidfowl时间。和适当的公告。如果信息更清晰，人们就不会那么惊讶了。

khellang 于 2017-05-09

👍7

@davidfowl时间。和适当的公告。如果信息更清晰，人们就不会那么惊讶了。

我理解，但我认为这不会影响您真正移植任何东西的能力。相同的 EOL 政策仍然存在。

davidfowl 于 2017-05-09

好的，在很难理解这个问题之后，我想为像我这样挣扎并且有一些疑问的人带来一些见解。

所以如果理解正确，我们最终会用netstandard代替net framework。

所以让我们假设 netcore 不存在并且 aspnet core 基于 netstandard。这意味着功能会变慢。

例子：
2017 asp.net 想要 Feature A。
2018 netstandard 实现了 Feature A。我们在 ns 上得到了 Feature A。

团队所说的是让 netcore 不基于 netstandard，所以：
2017 asp.net 想要 Feature A
2017 aspnet 团队实现 Feature A。Asp.Net Core 在 netcore 上得到 Feature A。
2018 netstandard 实现了 Feature A。我们在 ns 上得到了 Feature A。

所以，这个决定实际上给方程式带来了更多的“灵活性和速度”。更快地发布谁可以使用它们，反馈等。我认为这是对缓慢和平的网络框架的一个很好的补充。功能到了NS就真的成熟了。

如果拥有基于 netstandard 2 的 netcore 意味着功能会在 1 年后（或任何时间范围）发布，那么人们仍然会争辩说他们想要这个吗？这是我们习惯使用NET Framework的场景。

这是 aspnet 团队的天堂，能够在不依赖其他人的情况下运送东西，对于能够快速获得这些东西的客户来说，这也是一个好消息。如果您不能使用快速的东西，那么坚持使用以前的版本是一个合理的权衡（以及您/依赖项升级的动力。）

图书馆作者仍应以 netstandard 为目标，如果可以，则完全不用担心。
如果您需要一些不在 netstandard 上的东西（也许是 razor pages（？）），那么您必须以 netcore 为目标，在场景 1 中，可能甚至不存在 razor pages。我不明白这有什么不好，我会说这是公平的。

所以问题是，您现在有哪些依赖项限制了自己从 NET Framework 转到 Net Core ？
我可能是这里唯一的人，但我从没想过 aspnet core 会永远在 NET Framework 上工作，对我来说很明显这是一个“过渡”步骤。我目前需要 NET Framework 的所有开发都是splited 。（不，这不是微服务，它比这简单得多）。

2.x 支持和 3.x 丢弃与 1.x 支持和 2.x 丢弃没有什么不同。我在这里猜测一下，说人们并没有清楚地理解这个场景，所以我希望这至少能澄清一些。

@NickCraver你说你希望微软恢复这个决定。你有什么建议，不要有一个独立的网络核心并且有更慢的功能发布？（诚实的问题）

@davidfowl我认为当前提案可能存在一个让开发人员担心的微妙隐藏问题。
如果您有 asp.net 的功能 A（带有 netcore），那么您可以营销和发货（并勾选管理/pm 复选框）并“懒惰”地在 netstandard 上实施，如果我没记错的话，这就是“投注”关于不确定的，请参考这里。
因此，在我之前的示例中，netstandard 实现功能 A 可能在 2019 年或 2020 年，或者永远不会代替 2018 年。<-- 这看起来像是一个可能的问题（？），对吗？微软可以在这里做些什么吗？

Bartmax 于 2017-05-09

👍1

虽然我们在是否喜欢该公告方面都存在分歧，但确实感谢@davidfowl @DamianEdwards和@shanselman花时间讨论。这进一步证明了参与度和开放性的提高。

我相信有些人会在时间等问题上争论不休，但这是进步。

penderi 于 2017-05-09

👍1

例子：
2017 asp.net 想要 Feature A。
2018 netstandard 实现了 Feature A。我们在 ns 上得到了 Feature A。
团队所说的是让 netcore 不基于 netstandard，所以：
2017 asp.net 想要 Feature A
2017 aspnet 团队实现 Feature A。Asp.Net Core 在 netcore 上得到 Feature A。
2018 netstandard 实现了 Feature A。我们在 ns 上得到了 Feature A。

他们应该做的是：
2017 aspnet 团队构建了 lib X 所需的功能，支持 netstandard2.0。这样，aspnet 可以在所有 .netstandard 上运行，然后用户可以在 .net full 上运行它，因为 lib X 也可以在 .NET full 上使用（它只是一个 nuget 安装）。

相反，他们不这样做，他们强制 lib X 仅是 .NET 核心（否则，为什么首先要使用此线程/决策）。如果 lib X 非常先进以至于它需要 CoreCLR 功能，微软不得不问自己为什么这些高级功能没有移植到 .NET 完整 CLR。

总而言之，这感觉像是一种政治，MS 需要一个快速移动的 .NET 核心/aspnet 核心来为 Azure 客户提供一个堆栈，该堆栈可用于 azure 上的容器，因此它可以与 AWS 或 Google 云上基于 JVM/NodeJS 的容器竞争。从他们的商业角度来看，我什至可以理解这一点。但它表明，MS 没有优先考虑 .NET full 以更快地前进，因为它没有在 .NET full 上投入足够的资源来跟上 .NET core 的步伐。查看过去 2 年中添加到 .NET full 的 API 数量。这是否告诉您一个大型团队正在为此努力？

不。

Microsoft 销售大型数据库系统 SQL Server Enterprise。它带有精美的加密功能。 .NET 核心不支持。将 .NET core 2.0 卖给那些是该昂贵数据库系统的潜在客户的企业，玩得开心。

您可能想“快速”移动，但除非您完全了解您要前往的目的地，否则先花一两分钟做出决定会有所帮助。

FransBouma 于 2017-05-09

👍4

我越想越觉得大多数人的问题是他们觉得我们正在切断 .net 和 asp.net 之间的联系。
目前我们有asp.net、asp.net core(.net)、asp.net core(core)。因此，您可以选择不使用、少使用或使用全部核心。

由于版本控制沟通不畅，人们认为这只是创新和继续前进的最后一部分，而 asp.net 和 asp.net core (.net) 则停滞不前。
由于我们无法验证 lib 是否可以在 netstandard2.0 中正常工作而无需尝试，因此在新项目中使用完整核心非常危险。所以他们最终得到了 asp.net（旧）或 asp.net core（也旧）。
而且由于两者都很旧，因此只使用 system.web 和旧的 asp.net 是有意义的。既然他们知道这一点，而且 asp.net 核心无论如何都是 EOL，为什么还要麻烦。

所以我们最终只选择了勇敢的核心，其余的则使用旧但稳定的 system.web。我们将永远被一个更加支离破碎的生态系统所困。

PS：我的措辞与当前的感觉相同。与 2.x 相比，asp.net core 1.x 是“过时的”。这不是事实，而是人们的想法。

hallatore 于 2017-05-09

👍1

@davidfowl

如果每个 .NET 平台都按照自己的节奏移动，那么使用最新的 .NET 标准意味着移动速度较慢的框架得到的东西更少。

这已经发生了，我们可以接受。 Versions文档通常用_vNext_ 填充。这很好。与其等到所有平台都达到同等水平后再增加标准，我宁愿看到标准提前定义了几个版本，然后观察平台赶上来。人们甚至可以参与定义和实施。如果 ASP.NET Core 以该标准为目标发布，那么一旦平台和架构实现了该新标准，该包就可用。新的标准版本可以通过 VS 更新或软件包进来。

它的呈现方式，尽管 .NET Standard 听起来不像是社区计划的工作。它更像是通过审查的已实施合同的快照。如果主要项目没有针对它，那么对于它的发布就不会有那么多的计划。

我们做同样的事情

哦好。共同的苦难是最好的苦难。顺便说一句，带有平台/配置内容的 Csproj 和 sln 文件真的很烦人，因为并不总是声明构建组合 - 它们是推断出来的。所以 VS 可能会认为我的构建组合比实际存在的要多，因为它假设每个可能的组合都很重要。如果我可以声明平台/配置组合，我必须在文件中包含不需要的额外部分。就像您如何在 csproj PropertyGroup元素中使用Substring之类的函数来简化自定义属性一样，但是这些条件用于确定构建配置，因此您必须在其中包含完整的字符串值。这种事情不应该像现在这样麻烦。

诚实的问题（这是我问的不是微软），你更喜欢兼容性而不是新功能吗？如果是，为什么选择 ASP.NET Core？

就个人而言，没有。只要有一种方法可以做我需要做的事情，我不介意重写代码，只要它不是一项没有什么好处的巨大努力或需要测试的 PITA。所以我会选择最有动力和潜力的东西。但我必须处理跨多种技术的项目——Win32、COM、CORBA、ADO.NET、几个报告引擎、各种 Web API、嵌入式浏览器，如 CEF/Firefox/IE（当然没有优势，因为它不受支持）和多个特定于供应商的事情我会避免羞辱。我实现了我能做的一个插件，但在大多数情况下，我嫁给了主机可执行文件上的最小公分母。处理这么多技术很烦人，但它们是静态的。这就是很多桌面/服务器的东西。只要我有互操作的工具，我就可以做到。但我记得的不推荐使用的框架越少越好。

不过，ASP.NET 是 Web 堆栈的一部分，而 Web 堆栈是我认为需要保持最新的东西。它有一个不同的用例，不幸的是，除非有充分的理由不这样做，或者代码库明显不兼容，否则会使用较新的平台进行 Web 工作。我尽量保持更新，因为 Web 标准变化迅速且显着。大多数与网络保持同步的人都在坚持使用新技术，而在旧堆栈上实现新东西可能会相当痛苦。尤其是在 ASP.NET 与 PHP 和 Node 竞争的情况下，我必须保持更现代的堆栈来吸引人才和兴趣。我愿意做更少的网络工作，但不幸的是这是新的 UI 期望。我希望坚持标准能让我两全其美，但这似乎是限时优惠。

ZigMeowNyan 于 2017-05-09

👍1

所以如果理解正确，我们最终会用netstandard代替net framework。

不是那不正确。我不确定你是如何得出这个结论的。 .NET Standard 将始终是支持它的每个运行时的子集。

我想在这里抛出一些疯狂的东西，因为它已经被提到过几次了。我要说的与会发生什么无关，现在都是猜测。有几个人问我们为什么要针对 .NET Core 而不是 .NET Standard。

我们已经将字符串确定为我们希望在 .NET Core 中尝试解决的主要问题之一，有很多想法，但其中之一是默认将字符串设置为 utf8（大量兼容问题，但请在此处关注我）。
我们想要修复的另一件事是能够获取廉价的数组/字符串切片，任何连续内存。我们已经添加了Span<T>并正在查看Buffer<T>来表示这一点。这可能意味着 String 和 Array 实现了新的接口，使获取需要 0 分配的切片成为可能。
这导致 String 上的新方法允许拆分而不是每次都分配数组。
这会导致使用Span<char>和Span<byte>的 Int、UInt 等 (TryParse) 重载。
这导致采用Span<byte>的新编码例程。
Buffer<T>和Span<T>让您以统一的方式表示内存，我们希望升级网络堆栈以允许传递采用Span<T>或Buffer<T>的预固定缓冲区
Kestrel 将在 2.x 时间范围内实现 HTTP2（目前针对 2.1），这需要 SSL 流上的新 API 来执行 ALPN（https://en.wikipedia.org/wiki/Application-Layer_Protocol_Negotiation）。
.NET Core 上的 Http 客户端支持双工流式传输，它可以通过单个非 websocket http 请求在信号器中通过 http 实现流式传输端点。
我们从 HttpClient 和 System.Net.Http 分叉了标头解析器实现并将它们重命名（https://github.com/aspnet/HttpAbstractions/tree/d1d9bceff56cb44a194ae36923ce687e5e353006/src/Microsoft.Net.Http.Headers），以便我们可以改进它们并让它们同时支持 .NET Framework 和 .NET Core。 .NET Core 有一份这些改进的副本，因为没有必要改进它们（我们无法使用它们），所以没有恢复。
有一堆新的线程原语需要新的 API，如果我们能够使用它们，它们将点亮新的场景（https://github.com/dotnet/corefx/issues?q=is%3Aopen+is%3Aissue+ author%3Adavidfowl+label%3Aarea-System.Threading），这些只是我个人提交的一些内容。

如果没有修改核心原语的能力，我们鼓励将它们分叉并制作看起来像它们但不是它们的东西。这就是我们在 ASP.NET Core https://github.com/aspnet/Common/tree/dev/src/Microsoft.Extensions.Primitives 中拥有自己的小 BCL 的原因。

那只是我可以看到我们在短期内所做的事情的随机转储，这些事情会影响 .NET 的非常基本的部分。

davidfowl 于 2017-05-09

👍25 🎉1

@FransBouma

NET full 以更快地前进，因为它没有在 .NET full 上投入足够的资源来跟上 .NET core。查看过去 2 年中添加到 .NET full 的 API 数量。这是否告诉您一个大型团队正在为此努力？

那不是真的。事物不断地移植到 .NET Framework，但众所周知，风险比在 .NET Core 中进行相同的更改要高得多。当 .NET Framework 的更新破坏了您的应用程序时，你们不都讨厌它吗？我们也这样做，因此我们发明了各种流程来缓解它，你不会相信它对工程的维护它的扼杀。尽管所有这些，我们仍然设法完成功能。也就是说，它永远不会像 .NET Core 那样快速移动，它是一个按 Windows 时间表发布的 Windows 组件。

davidfowl 于 2017-05-09

我理解，但我认为这不会影响您真正移植任何东西的能力。相同的 EOL 政策仍然存在。

@davidfowl正确。但是你如何构建它意味着一些东西。更不用说什么时候沟通了，如果有的话。它不一定会给人们更多的时间来做实际的工作，但它会给他们更多的时间去思考和做出正确的决定（对他们来说）。

目前，如果您已经开始在 .NET Framework 上移植到/使用 ASP.NET Core，您似乎有三个选择：

将所有代码和依赖项移植到 .NET Core 并迁移到 ASP.NET Core 2.x。
- 这将是最佳解决方案，但它可能需要大量工作，并且对于某些人来说，由于 3rd 方库，它甚至可能超出他们的控制。
继续使用 ASP.NET Core 1.x 和 .NET Framework，并希望您能够在 1. 不受支持之前做到这一点。
- 这是相当冒险的。在一年内（或两年，或三年？谁知道呢？），您可能会冒险在不受支持的平台上运行。
回到 ASP.NET 4.x
- 虽然这种替代方案让您得到支持，但您将“返回”并撤消已经开始的工作。而且，让我们面对现实吧；这个平台不会得到太多的爱。

如果您提前知道并可以计划，我认为 1. 和 2. 都是不错的选择。问题是这两种选择都有很多未知数。图书馆 A 呢？图书馆 B 呢？库 A 会被移植吗？

现在，我认为很多人觉得他们被迫做出选择，而没有清楚地了解选择的实际含义。

khellang 于 2017-05-09

👍22 ❤2

@khillang （在您的假设解决方案中）

迁移到 .NET Framework 上的 ASP.NET Core 2.0
- 这是相当冒险的。一年之内，您可能会冒险在不受支持的平台上运行。

davidfowl 于 2017-05-09

@davidfowl

诚实的问题（这是我问的不是微软），你更喜欢稳定性和兼容性而不是新功能吗？如果是，为什么选择 ASP.NET Core？

老实回答：
赞成：稳定性和兼容性是最重要的。新功能很好，但当它们落地时，它们根本不能破坏现有的生态系统。
为什么选择 ASP.NET Core：因为它运行在 OS X 和 Linux 上。

企业选择像 .NET（旧的和/或核心）或 Java 这样的生态系统。当他们做出决定时，他们会投入大量精力为该平台/生态系统开发代码。

现在，例如，我们的一位客户已经在 ASP.NET Core 上投入了大量资金。根据 .NET Core 之前的公告和销售的想法，编写了代码。这个新的 (ASP.)NET Core 代码是我们（痛苦地）在 (ASP).NET Core 的初始开发过程中与一个团队一起编写的，从一开始就是一组服务器和客户端库，有很多的业务逻辑。
这段代码，除了在 Linux 服务器上运行、提供服务外，目前还被用于一组非常古老的与这些服务通信的应用程序，这些是 WPF / Windows Forms / C++/CLI 和普通程序的混合体C++（包括 DirectX 的东西）。

而现在您只是简单地切断了我们的客户在现有应用程序的 .NET Core 代码上花费数年时间的投资，因为在实际应用程序中重新使用新的 .NET Core 代码是不可能的（为新服务器和业务逻辑库构建）。

回到问题上来：企业会选择 .NET Core 作为“.NET，现在也用于 XPlat”，同时期望 .NET 在过去 17 年中为我们提供的兼容性和稳定性。而且，坦率地说，这是 .NET Core 的唯一原因。如果你不想这样，你会使用 Node.js 甚至 Java。现在两者都比 .NET Core 成熟得多，XPlat 也更成熟。

而且，只是稍微详细一点：.NET Core 在早期阶段很酷，而且节奏很快，有 project.json 和所有。然后，出于“与 .NET 的兼容性”的原因，project.json 再次被我们拿走，转而支持 Msbuild 和 .csproj。现在，这种“与 .NET 的兼容性”的好处也被剥夺了，取而代之的是......究竟是什么？

gingters 于 2017-05-09

👍6 ❤1

@gingters

首先，很好的回复！

为什么选择 ASP.NET Core：因为它运行在 OS X 和 Linux 上。

基于此，单声道上的 MVC 5 似乎是您真正想要的，对吧？

回到问题上来：企业会选择 .NET Core 作为“.NET，现在也用于 XPlat”，同时期望 .NET 在过去 17 年中为我们提供的兼容性和稳定性。而且，坦率地说，这是 .NET Core 的唯一原因。如果你不想这样，你会使用 Node.js 甚至 Java。现在两者都比 .NET Core 成熟得多，XPlat 也更成熟。

而且，只是稍微详细一点：.NET Core 在早期阶段很酷，而且节奏很快，有 project.json 和所有。然后，出于“与 .NET 的兼容性”的原因，project.json 再次被我们拿走，转而支持 Msbuild 和 .csproj。现在，这种“与 .NET 的兼容性”的好处也被剥夺了，取而代之的是......究竟是什么？

这基本上是问题的症结所在。根据您的评估：

在 (ASP).NET Core 的初始开发过程中，我们（痛苦地）与一个团队一起编写了这个新的 (ASP.)NET Core 代码。

您真的只是想要 Linux 上现有的 .NET Framework 具有良好的旧 ASP.NET 4.x 兼容性。这是一个公平的总结吗？

davidfowl 于 2017-05-09

赞成：稳定性和兼容性是最重要的。新功能很好，但当它们落地时，它们根本不能破坏现有的生态系统。

.NET Core 实际上是一个比 Desktop 更稳定的平台，因为它允许在 Desktop 不支持的情况下并行执行。

如果您想在下一版本的 Desktop 中使用更新的功能，您需要将整个计算机升级到该新版本，这会影响该计算机上的所有内容，而不仅仅是想要使用更新功能的应用程序。如果您有一个用于单一目的的专用服务器，那很好；但如果您在同一台服务器上运行许多应用程序以不同的速率升级（或根本不升级！）

benaadams 于 2017-05-09

👍4

@davidfowl写道：

由框架决定是否要在 .NET Framework、UWP、.NET Core、mono 等上运行。这是一种选择。 Orleans 不附带 .NET Core。 ASP.NET Core 可以。那些产品是一样的。

在 Orleans 的案例中，我们在“2.0 技术预览”版本中支持 .NET Standard 1.5，但一直在等待 .NET Standard 2.0 以便我们能够发布稳定版本。目前我没有看到任何阻碍我们的因素——我只关心未来的分歧。不过，这种分歧必须在某个时候发生。

👍 非常感谢您坚持回答大家的问题， @davidfowl & co！

ReubenBond 于 2017-05-09

👍4

NET full 以更快地前进，因为它没有在 .NET full 上投入足够的资源来跟上 .NET core。查看过去 2 年中添加到 .NET full 的 API 数量。这是否告诉您一个大型团队正在为此努力？

那不是真的。事物不断地移植到 .NET Framework，但众所周知，风险比在 .NET Core 中进行相同的更改要高得多。当 .NET Framework 的更新破坏了您的应用程序时，你们不都讨厌它吗？我们也这样做，因此我们发明了各种流程来缓解它，你不会相信它对工程的维护它的扼杀。尽管所有这些，我们仍然设法完成功能。也就是说，它永远不会像 .NET Core 那样快速移动，它是一个按 Windows 时间表发布的 Windows 组件。

这忽略了您可以将_you_依赖的库作为 netstandard2.0 软件包发布的事实，因此 aspnet 也可以在 .net full 上运行。此外，对 .NET 进行完整更改并非没有风险，但请不要让它听起来像是一堆组织得很糟糕的代码，其中一次更改可能会使一切崩溃。

尽管所有这些，我们仍然设法完成功能。

是的，其他所有 .NET 开发人员也是如此；）一旦你发布了一些东西，你就会被那个 API 困住，我们都有这个。但是，您想走捷径（就像 ASPNET 团队以前做过很多次一样！）并在没有负担的情况下移动。但这最终不会飞。

也就是说，它永远不会像 .NET Core 那样快速移动，它是一个按 Windows 时间表发布的 Windows 组件。

我想我们有问题的症结所在，对吧？ .NET 核心团队可以做他们想做的事，而无需与庞然大物“WinDiv”沟通。为什么微软不在内部解决这个内部政治问题，并确保 .NET full + .NET core 在没有 Windows 政治的情况下进行版本控制/正确移动？

顺便说一句，您仍然对如何将 SQL Server Enterprise 的加密 API 销售给 .NET core 2.0 用户感兴趣。

FransBouma 于 2017-05-09

另外，我必须补充；我对这个话题持续了多长时间印象深刻，有这么多人参与，同时仍然保持文明❤️ 这不是你每天在 internetz 上看到的东西 👏 也许 .NET OSS 生态系统毕竟正在成长？ 😉

khellang 于 2017-05-09

❤35

这忽略了您可以将所依赖的库作为 netstandard2.0 包发布的事实，因此 aspnet 也可以在 .net full 上运行。

此外，对 .NET 进行完整更改并非没有风险，但请不要让它听起来像是一堆组织得很糟糕的代码，其中一次更改可能会使一切崩溃。

它很大并且已经存在了很长时间。像任何遗留系统一样，某些部分比其他部分更好。它不会降低代码的可靠性，但它确实使某些部分几乎无法更改。有很多有趣的故事，老手可以告诉你一个领域的错误修复如何打破其他部分应用程序中的模糊场景。它很纠结，当依赖边界没有很好定义时就会发生这种情况。您甚至不必相信我，只需浏览 referencesource.microsoft.com。就地更新是我们需要为 .NET Framework 的单个潜在破坏性更改添加配置开关的原因。这是物理学，它只是不能移动得那么快。

是的，其他所有 .NET 开发人员也是如此；）一旦你发布了一些东西，你就会被那个 API 困住，我们都有这个。但是，您想走捷径（就像 ASPNET 团队以前做过很多次一样！）并在没有负担的情况下移动。但这最终不会飞。

我们喜欢捷径！开发人员很懒惰😄。我们还希望在不破坏 .NET Framework 所代表的内容的情况下真正改进我们的 .NET Core。也许我们应该把它重命名为别的东西，比如 Sparkle 😄。

我想我们有问题的症结所在，对吧？ .NET 核心团队可以做他们想做的事，而无需与庞然大物“WinDiv”沟通。为什么微软不在内部解决这个内部政治问题，并确保 .NET full + .NET core 在没有 Windows 政治的情况下进行版本控制/正确移动？

阅读我关于物理学的其他答案。

顺便说一句，您仍然对如何将 SQL Server Enterprise 的加密 API 销售给 .NET core 2.0 用户感兴趣。

这不是我的专业领域，我会让其他人回答这个问题。

davidfowl 于 2017-05-09

👍1

@khillang哈哈，那是因为 GitHub 问题还没有吸引到讨厌 MS 的巨魔。目前，Twitter 是他们的媒介，还没有反对意见：)

dustinmoris 于 2017-05-09

@davidfowl

您真的只是想要 Linux 上现有的 .NET Framework 具有良好的旧 ASP.NET 4.x 兼容性。这是一个公平的总结吗？

不，不是。我们的客户需要完整的新/闪亮（微）服务，以补充他们现有的 .NET 4.x（我们开始时它们是 3.5）Windows 桌面应用程序。

当您使用所有闪亮的核心内容进行测试时，我们开始在 ASP.NET Core 之上为全新的 MVC 编写新的服务器代码，以及随附的 DTO、业务逻辑和客户端库，这些也正在在现有的 4.6 桌面应用程序中并行使用以与全新的服务器通信。

此外，一些全新的 ASP.NET Core 服务器不仅可以在 Linux 上运行，还可以作为带有 Topshelf 的 Windows 服务（在完整的 4.6 框架之上）。

所以问题是，已经进行了大量投资，现在我们似乎被 .NET Core 1 困住了，因为继续使用 2（并失去 netstandard）也意味着，我们不能重用现有的桌面应用程序（服务和随附的库是为其创建的）。

所以对我们来说最重要的事情是仍然能够使用我们在 .NET 4.6 桌面应用程序中编写的新 (ASP).NET Core 库（因为这就是它们的构建目的），同时能够保持在受支持的.NET Core 版本，只要支持桌面 .NET 版本，代码就可以在其中运行。

因此，只要 .NET Core 1. 像 .NET 4.6 一样受到支持，并且当 .NET 5 出现时，.NET Core x 有一个线性升级路径，并且 .NET Core x 代码能够在 .NET Core x 上运行。 NET 5，那么我们很好。

gingters 于 2017-05-09

@gingters您是否在 asp.net 服务上使用 netstandard2.0 中没有的 .net 功能？

如果没有，那么库应该可以工作。但我猜你说的是netstandard2.0中没有的东西。

hallatore 于 2017-05-09

@davidfowl c++/cli dll 可以在 netcoreapp 2.0 上运行吗？我们有旧的 3rd 方 C++/CLI 程序集，不会很快被替换。

qrli 于 2017-05-09

@davidfowl写道：

ASP.NET Core 2.0 确实没有那么多新功能

在这种情况下，为什么现在发生这种极具破坏性的变化？

idg10 于 2017-05-09

👍15

@qrli C++/CLI 不适用于 CoreCLR。以下是有关为什么不支持它的一些背景： https ://github.com/dotnet/coreclr/issues/659#issuecomment -91341753

gulbanana 于 2017-05-09

为 1x 提供 4 年支持（尽可能从 2x 移植），然后继续快速使用 2x。用于慢速城市交通的城市汽车和用于高速公路的法拉利。我们在.net 世界之外有很多竞争。
如果 ASP.Net Core 成功，我相信 MS 会提供资源来支持 1x 4 年。大多数情况下，文化会改变。

stefan2410 于 2017-05-09

👍2

@idg10真的不是。 2.x 几乎是 1.x，具有仅在核心中可用的性能内容。我认为唯一的主要功能是 Razor Pages。

因此，使用 1.x 版本并不意味着您使用的是过时的版本。但这并没有很好地传达。

hallatore 于 2017-05-09

👍1

在这种情况下，为什么现在发生这种极具破坏性的变化？

猜猜这几乎总结了它https://github.com/aspnet/Home/issues/2022#issuecomment -300141134

Bartmax 于 2017-05-09

@hallatore
我知道它有效，就像_now_一样。我们现在可以停留在 1 上。问题还在继续。当我们想要（或更糟：需要）升级到 (ASP).NET Core 2 库时（即当 1 停止服务，并且修复了一个关键的安全漏洞时）我们面临着无法升级的问题，因为这将使我们无法在 .NET 桌面应用程序中使用需要升级包的库。

编辑/添加：除非有一个新的完整 .NET 框架能够运行新的、固定的 .NET Core 库，该库位于现有旧桌面应用程序的线性升级路径上。

gingters 于 2017-05-09

@gingters不确定我是否理解。

如果您的桌面库与 netstandard2.0 一起使用，它们也应该在核心上运行。（如果他们调用 wpf 的东西等，他们当然不会）
如果是这种情况，那么您应该能够使用 asp.net core 2.0。

如果您的桌面库在核心上崩溃，因为它们使用了 netstandard2.0 之外的东西。然后我明白为什么你需要留在 1.x 上。我明白为什么短 EOL 是个问题。

如果您知道 2.x 只包含大部分核心性能的东西（意味着 1.x 与 2.x 相比没有过时），那么 1.x 会是一个更容易/更好的选择。那个 1.x 将获得补丁并支持 * 年？

hallatore 于 2017-05-09

@hallatore这是相反的方式。旧应用程序：混合 Windows 窗体、WPF、C++/CLI、普通 C++、DirectX、数百万行代码等 pp，在 4.6 完整框架上运行。

在 .NET Core 上：新的业务逻辑库（也使用其他库，即 Serilog 的 .NET Core 版本），这些服务的抽象库 + 服务 + 客户端库。服务需要在 Linux 上运行并作为 Windows 服务运行（目前 Topshelf 在完整的 .NET 4.6 框架上，不过，一旦 Windows 服务支持登陆 Core 就可以更改）。

现在，新的业务逻辑和抽象以及服务客户端库也从 .NET 4.6 应用程序中使用。这意味着我们无法升级它们，因为只要桌面应用程序运行，它们就需要在完整的 .net 框架上运行（我们可以假设只要桌面可以存在，除非完整的框架一般会消失）。

gingters 于 2017-05-09

@gingters您仍然可以在您的解决方案中拥有针对 netstandard _min(usable)_ 的共享库项目，并从您的 ASP.NET Core 2.0 代码中使用这些库，并将它们打包以供 WPF、Xamarin、UWP 等使用。

markrendle 于 2017-05-09

很遗憾你们这些 MS 家伙仍然不明白这一点。您仍然认为这只是 api 差距问题。你仍然认为人们可以只修改他们的代码，它就可以在 netcoreapp 上运行......我认为你比谷歌更了解企业。

qrli 于 2017-05-09

👍2

基于此，单声道上的 MVC 5 似乎是您真正想要的，对吧？

@davidfowl我的意思是，来吧。这是一个轻蔑和坦率的侮辱性答案。 MS 的任何人都可以确认单个开发人员甚至已分配给 Framework ASP 吗？我不是想在这里做个混蛋，但似乎有时社区会被说服。

在阳光下，我没有理由认为 .Net Core 和 ASP.Net Core 是同一个产品。根本没有任何消息支持它。尤其是当您考虑到 Mono 在 .Net Core 公告之后_属于微软的翼下时。它一直被认为是 .Net 的更小、更灵活的 xplat 版本。不仅如此，我们都记得 ASP.Net Core 实际上是 ASP.Net 5 并且可以在任何地方工作的日子。哎呀，这种变化只是一年半前而已。

netstandard20 中的自托管 HTTP 故事是否有效地“使用 Kestrel 1.x”？我不确定 Nancy 的人是否会非常关心这一点，我也不会。ASP.Net 2.x 可能是增量功能，但 Kestrel 2 有一个严重的性能优势，我们可以认真使用它的那一天出来。

mattnischan 于 2017-05-09

👍1

@davidfowl

它很大并且已经存在了很长时间。像任何遗留系统一样，某些部分比其他部分更好。它不会降低代码的可靠性，但它确实使某些部分几乎无法更改。有很多有趣的故事，老手可以告诉你一个领域的错误修复如何打破其他部分应用程序中的模糊场景。它很纠结，当依赖边界没有很好定义时就会发生这种情况。

我认为这是一个有趣的评论。我记得看过一个较旧的 NDC 会议记录， @davidfowl和@DamianEdwards挑选了您真正想留下的 ASP.NET 4 中的遗留问题 - 窥视那个黑匣子代码真的很有趣。

但我认为这个评论也反映了我们许多人对我们自己的代码库的担忧。我们维护大型遗留系统，这些系统通常设计得不好，依赖边界很差。为 .NET Core 重写其中一些系统实际上是不可能的。企业根本不会允许发生如此大的变化的风险。

我不知道正确的答案是什么。但我知道，对于我们自己的应用程序，在可预见的未来，我们将使用完整的框架和 ASP.NET4/MVC5（我们仍然有很多 WebForms 在相当长的一段时间内不会被重写！）。我希望看到 MVC5 得到一些喜爱，因为它_finally_迁移到了 GitHub——我什至愿意贡献我自己的时间和精力来让它变得更好（例如更好的异步支持、性能改进等）。

jdaigle 于 2017-05-09

👍3

@qrli Enterprises 仍然有完整的 .NET 4.5 可以在其 Windows Server 2008 R2 IIS 7.5 Web Farms 上运行。没有人会从他们那里夺走这一点。

markrendle 于 2017-05-09

@mattnischan

netstandard20 中的自托管 HTTP 故事是否有效地“使用 Kestrel 1.x”？我不确定南希的人会非常关心这一点，我也不会。

HttpListener是 netstandard20 的一部分，因此 netcore20 也没有通过 netcore20 在这方面被带走。

benaadams 于 2017-05-09

HttpListener是 netstandard20 的一部分，因此也是 netcore20。

而且我想我可以期望来自HttpListener的每秒相同的请求？

mattnischan 于 2017-05-09

@markrendle是的。目前。

但是，当我们共享的东西使用的另一个库（即 serilog、newtonsoft、autofac 等）放弃对 netstandard_min(usable) 的支持时，您会建议什么，（可能只是因为他们觉得支持这两个世界需要付出太多努力）和在仍然支持完整框架的最新版本中检测到一个严重的安全问题？

gingters 于 2017-05-09

@mattnischan

HttpListener 是 netstandard20 的一部分，因此也是 netcore20。

而且我想我可以期望来自 HttpListener 的每秒相同的请求？

好吧，Nancy 是 .NETStandard 1.6，因此您可以在 Core 2.0 上使用它并使用 Kestrel 2.0。更好的？

benaadams 于 2017-05-09

@gingters我建议您在到达时越过那座桥。

永远不要让未来打扰你。如果必须的话，你会用今天武装你对抗现在的同样的理性武器来迎接它。
_~ 马库斯·奥勒留_

markrendle 于 2017-05-09

在交付没有维护预算且必须在未来几年内基本保持不变的软件时，这不是一个有用的口头禅。

gulbanana 于 2017-05-09

👍1

如果它必须在未来几年内基本保持不变，那么它所依赖的图书馆在未来几年会发生什么事情又有什么关系呢？

markrendle 于 2017-05-09

👍1

@markrendle现在假设法律要求您（至少在某些国家/地区）在应用程序版本发布之前为这些情况提供紧急协议，因为它可能用于人们生命可能受到威胁的环境.

gingters 于 2017-05-09

👍1

所以你想要一个和 Kestrel 一样快的 Web 服务器，而你唯一的具体要求是它不是 Kestrel？

好吧，Nancy 是 .NETStandard 1.6，因此您可以在 Core 2.0 上使用它并使用 Kestrel 2.0。更好的？

@markrendle @benaadams不，我认为您误解了，再说一遍，不是想成为一个混蛋，只是指出还有其他客户的 ASP.Net Core 并不是全部。我只想在 Kestrel 2.0 发布时将我们的生产平台托管在它之上，而我们的生产平台可能会在 Framework 上运行一段时间。我无法定位 netcoreapp20。

Nancy 可能是 netstandard16，但没关系，因为除了 Core 2.0 之外，我不能使用 Kestrel 2.0。我意识到这是特定的，也许答案真的是“然后编写你自己的网络服务器，它可以在与 Kestrel 2 一样快的框架上运行。Kestrel 仅适用于 ASP.Net。” 但我不希望这是信息。

mattnischan 于 2017-05-09

@gingters @gulbanana我不明白带有一组固定依赖项的已发布应用程序将如何中断，因为开源项目在某个假定的未来日期停止支持任意版本的底层框架。

markrendle 于 2017-05-09

@mattnischan是的，我明白你的意思并删除了该评论:)

markrendle 于 2017-05-09

👍1

@stefanolson

因为我需要在服务器和我的桌面应用程序之间共享代码，这是否意味着我永远无法拥有最新版本的 ASP.Net？

如果您的库以 .NET Standard 为目标，则可以在 Desktop 和 Core 中使用它们。对于面向 .NET Standard 的库，您将获得通用平台支持：Desktop、Core、Mono、Unity、UWP、Tizen 等

ASP.NET 应用程序是可执行文件；终点，它不是图书馆。最终输出，ASP.NET 应用程序/可执行文件需要在平台上运行。最终，它的任何平台库都将被 ASP.NET 应用程序使用，因此它们不是与平台相同的目标没有任何好处。

.NET Core 是一个很好的平台，因为它具有广泛的跨平台覆盖；可与Desktop并排安装，可逐个应用独立升级；而不是整台机器和每个应用程序。

有些物品在外面确实有用途；所以Wyam使用 Razor 来生成静态站点； Razor 目前是 .NET Standard 1.3，因此在 Core 之外使用它目前不是问题。

上面提到了一些边缘情况：

使用不支持 .NET Standard 2.0 功能集的库。其中很多都是希望可以填补的空白 - 在本期开始时，MS 询问这些空白是什么，以便他们可以优先考虑它们。

运行嵌入在例如 UWP 应用程序中的 WebApp；但是，如果 Desktop 仍受支持但更改为 4.7.1 版本，您仍会处于与 UWP 当前不支持 4.7.1 相同的情况，并且到它支持 ASP.NET 时需要 4.7.2，然后是 4.7。 3 等等。这将是一项西西弗斯式的任务，因为其他平台永远无法捕捉到它；所以这只是忙碌的工作而没有多大意义？

benaadams 于 2017-05-09

👍4

是的，我明白你的意思并删除了该评论:)

不用担心，好先生。 👍

mattnischan 于 2017-05-09

@davidfowl

ASP.NET Core revving 版本对此有何影响？如果我们在 3.0 中放弃了对 .NET Framework 的支持（正如人们似乎在此线程中所逃避的那样），无论如何，您不会陷入同样的死胡同吗？您将 ASP.NET Core 2.0 应用程序移植到框架上运行一年，当 3.0 发布时，您将无法升级。无论如何，您都可以使用在 .NET Framework 上运行的 ASP.NET Core 1.1.x 来执行此操作，即使在 ASP.NET Core 2.0 发布时也受支持。

只是说（据我了解）“有时我们需要与完整的 .net 决裂，为什么不现在”是缺少重要的一点。我敢肯定，很多人都在等待核心 2.0 的发布。因为它公开承诺在与完整 .net 的兼容性方面进行大量改进。如此多的图书馆作者也在等待开始向核心迁移。所以我猜想在 core 2.0 发布之后，我们会在 Core 上迁移更多的库。因此，将 asp.net core 绑定到 core 3.0 对生态系统的挫败感会比现在要小得多。因为在 3.0 的那一刻，这些应该减少从迁移到核心的阻碍。
现在是一场灾难。

以前我正在评估开始将我们的框架（与@benaadams描述的故事非常相似）迁移到 core/asp.net 核心的两个步骤：将 web 部件（现在在 mvc/webapi 上）迁移到 asp.net 核心并保持完整.net，然后在所有依赖项都具有相应的核心实现时迁移核心上的所有其他内容。目前阻碍我们的是 Oracle ADO 提供程序和 Postgres ADO 提供程序（corefx 中可能存在其他不兼容问题，我们尚未深入研究）。现在这个计划已经死了。所以我们必须坐下来等待依赖迁移，放弃核心世界中的所有新东西。而这一切仅仅是因为 MS 中的某个人决定我们需要“快速移动”的平台。

evil-shrike 于 2017-05-09

👍9

@markrendle该应用程序不会因此而中断。问题是另一个问题：
因为 .NET Core 2 放弃了对完整框架的支持（它在版本 1 中运行良好，而且它来自 Microsoft，你不希望在更新到新版本时放弃这样一个基本的基本功能），你的依赖项可能会尽快放弃对这种情况的支持。
有人在使用的一个库中发现了一个严重的安全问题，并且没有为您停留的版本发布更新，因为较新的版本不再支持您的运行时。现在，由于您的应用程序在非常受监管的环境中使用，您需要提供一个应急计划，说明当检测到关键安全问题时您将做什么以及如何推出该修复程序以防止人们受伤或更糟。 “好吧，我们无能为力”将导致撤销您发送该申请的许可。

gingters 于 2017-05-09

👍2

@gingters看，重点是，您必须根据当前可用的信息和公司运营所在市场的性质来做出技术选择。凭着世界上最好的意愿，你无法解释所有的可能性，无论世界上的官僚和监管者多么想假装你可以。如果 Microsoft 在被 Apple 恶意收购中被收购，而 .NET 完全停止支持 Swift 会怎样？如果强加密在您销售的国家之一被视为非法，并且所有包含 SHA256 的软件堆栈都被禁止，该怎么办？如果 Nicolas 或 James 或 _insert-name-of-Autofac-maintainer-here_ 决定搬到火星并成为水分农民怎么办？如果磁极反转并且数字记录数据的每一位都被擦除怎么办？

作为对您作为一家公司的实际回答，如果在 JSON.NET 中发现严重的安全问题（例如），在没有可用的官方更新的情况下，您将做什么，唯一的可能的答案是“我们将分叉和修补 JSON.NET”，我猜这已经是如果 James Newton-King 因任何原因变得不适，你会怎么做的问题的答案。在我之前在这些市场工作的经验中，有将源代码托管到专有包的托管安排，以应对这种可能性。与此相比，如何处理开源包是微不足道的。

markrendle 于 2017-05-09

❤1

而这一切仅仅是因为 MS 中的某个人决定我们需要“快速移动”的平台。

“快速行动”可能夸大了它；按照之前完整框架的发布时间表，最好将其表述为“不增加额外的 1 - 2 年延迟”。在网络世界中，这是一段疯狂的时间。

事情瞬息万变，平台需要保持相关性。

benaadams 于 2017-05-09

👍9 👎2

@davidfowl和@DamianEdwards我认为这整个混乱来自 ASP.NET Core 1.x 可以在 .NET Framework 上运行的事实。这就产生了 ASP.NET Core 是 ASP.NET 4/MVC5 演变的假设；使人们迁移到它认为他们将获得所有好处（速度和新功能），同时保持向后兼容性。

所以也许这个问题的长期/永久答案是重新推广 ASP.NET 4/MVC5，作为寻求与长期支持向后兼容的人的答案（并且可能也提供一些小的改进）。

然后，ASP.NET Core 可以专注于成为一个打破过去的新平台，为那些能够实现飞跃的人提供巨大的好处。

鉴于此，(ASP).NET (Framework) 和 (ASP).NET Core 将是客户可以选择的两条平行且同样有效的道路。我认为事情从一开始就应该是这样。

KPixel 于 2017-05-09

@markrendle是的，这是假设的，但遗憾的是官僚主义是真实的。是的，你不能（也不需要）考虑所有的可能性。只为那些你能预料到的。

现在我们遇到的情况是：a) 放弃一个完整的平台（.NET 完整框架），它在 .NET Core 1 中得到很好的支持，这不是你能预料到的。但是，既然它现在发生了，您可以 b) 非常肯定地预测您的其他依赖项中对 v1 的支持会下降，“是的，我完全可以看到这种情况迟早会发生”。

是的，分叉和反向移植修复是可能的解决方案之一，但这是您希望尽可能避免的事情。如果 .NET Core 团队说过类似“嘿。看，我们不打算在完整的框架上运行，不要依赖它”，或者甚至最好一开始就没有让这成为可能，这整个讨论没有必要，因为客户一开始就不会选择在 .NET Core 之上投资新产品。

gingters 于 2017-05-09

@gingters我认为我们已经到了您乐于在 .NET Core 2.x 或更高版本上运行 ASP.NET Core Web 位，并使用 .NET Standard 2.x 在 Core 和 Full/UWP/whatever 之间共享库的阶段. 因为如果这些库要放弃对 .NET Standard 2.x 的支持而只支持 .NET Core 2.x，那么它们也将放弃对完整 .NET 的支持，而无论哪种方式，你都会感到厌烦。

markrendle 于 2017-05-09

@markrendle直到不再支持 1x 之后我们需要在共享内容中使用的 ASP.NET Core 位之一存在严重问题。

gingters 于 2017-05-09

@gingters幸运的是它是开源的，如果需要，您可以支持自己（或支付第三方费用）！

adamhathcock 于 2017-05-09

@markrendle没有。纯粹的遗留项目是死的。企业项目通常是一个大型混合代码库，其中包含从几十年前到全新的代码/库。成为 netcoreapp 仅意味着您删除了混合的能力。所以我们不能再移动到你喜欢的新版本，而是锁定到旧版本。反微软的同事会很高兴地对我说“我告诉过你......”然后推动我们迁移到谷歌解决方案。

qrli 于 2017-05-09

👍6

我并不是在争论永远支持 netfx。但我强烈认为从现在起至少 2 年内 netfx 应该得到 asp.net core 的支持。不仅是 1.x，还有 2.x。

qrli 于 2017-05-09

👍1

@qrli那些“企业项目......包含代码/库的大型混合代码库可以追溯到几十年前的全新代码。” 是企业项目的所有问题，需要停止。抱怨一项新技术阻止你将更多的泥巴扔进一个用垫片、打包线和否认结合在一起的绝望大球中，就像抱怨一台新的工业激光切割机配备了安全功能，可以阻止你向前倾斜和切断你自己的重要部分。

markrendle 于 2017-05-09

👎4 👍4 ❤2

@benaadams

“快速行动”可能夸大了它；按照之前完整框架的发布时间表，最好将其表述为“不增加额外的 1 - 2 年延迟”。在网络世界中，这是一段疯狂的时间。
事情瞬息万变，平台需要保持相关性。

这是一个政治/组织限制，而不是技术限制。看看 JVM/Java 是如何移动的。如果他们在移动。仍然相关，远远超过今天的 .NET。所以“快速移动”并不是人们选择 Java/JVM 的原因。相反。他们选择 Java/JVM 是因为它没有与“快速移动”相关的所有缺点：它是一个稳定、可靠的平台，您的投资不会在 1-2 年内浪费掉。

我不知道，如果 MS 想要快速移动 .net，它会快速移动。他们拥有它，他们可以决定做什么。但它的权力并没有真正给予太多：.net full 对于它现在的位置来说已经“足够好”了。

MS 已经在方向盘上睡了很多年，现在突然之间，性能和内存压力之类的事情变得很重要（毫无疑问，它们确实如此），而在 JVM 中，许多人已经在运行时的这些特定方面进行了土地投资年，这是有回报的。

我不知道短期内的解决方案是什么，但从长远来看，让 .NET 分散在两个主要部门（.net full with windows，.net core with devdiv）除了相同之外没有共同点/目标雇主对我们这些外来者来说不是好兆头。

FransBouma 于 2017-05-09

👍10

虽然这里提出了很多观点，并且每个人都在努力确保自己理解其他人的观点，但像“大企业不应该那样”这样的解决方案却无济于事。即使你能说服他们，他们也需要 20 年才能不再那样，因为他们是大企业。

kolektiv 于 2017-05-09

👍4

@kolectiv是的，但接受企业不会突然停止成为企业并不意味着您必须积极鼓励/启用这种行为。

这也不应该意味着 _my_ 应用程序必须运行得更慢并且托管成本更高。

markrendle 于 2017-05-09

在我们大量使用的库上运行可移植性分析，这些库仍然针对 ASP.NET Core 1.x（EF6、NHibernate、NServiceBus）和 man上的 .NET 4.x，这些库甚至无法定位netstandard20 。

库 | 百分比
---------- | ---------
EF6 | 62.74
休眠 | 67.39
服务总线 | 65.68

在缺少 API 方面仍然存在巨大差距。 EF Core 和 EF6 还是有很大差距的，当 NHibernate 有 EF6 不存在的主要功能时，我们仍然使用 NHibernate。我们在任何进行消息传递的项目中使用 NServiceBus。

唷。

jbogard 于 2017-05-09

👍12

@markrendle

那些“企业项目......包含代码/库的大型混合代码库可以追溯到几十年前到全新的”。是企业项目的所有问题，需要停止。抱怨一项新技术阻止你将更多的泥巴扔进一个用垫片、打包线和否认结合在一起的绝望大球中，就像抱怨一台新的工业激光切割机配备了安全功能，可以阻止你向前倾斜和切断你自己的重要部分。

是的，让我们告诉那些讨厌的企业和大型组织以不同的方式做事，切断电线！阻止泥浆洪水！这将使他们醒来并倾听。哦，等等，这无济于事，因为他们已经知道这一点，但必须处理很多你不关心或忽略的事情来为你自己的论点。

看，没有人说“新技术：糟糕！”。这是关于追求新技术而没有意识到随之而来的后果。我们都喜欢使用最新的东西，而不必担心旧的东西，谁想要呢？然而，现实讲述了一个不同的故事。如果您只需要使用最新的位而不需要关心旧的东西，那对您有好处！可悲的是，我们在战壕中悲伤的工作无人机不得不面对不同的现实。如果你至少承认，对于很多人来说，现实就是这样，他们无法改变它，他们无法创造不同的未来，这是他们必须与之合作的。

FransBouma 于 2017-05-09

👍7

@markrendle我不太确定你的建议是什么？放弃我们的 1500 万行 C# 代码并重新编写它们？我们正在考虑（慢慢地）过渡到 netstandard 2.0，并希望在它出现时能够访问像 Span 等的东西，但是像这样的问题让我怀疑这是明智的。

我们想要 Linux 支持，但这更像是一种分歧。我曾假设 netstandard 将继续推进最先进的实现，然后框架之类的东西会迎头赶上，但至少我们知道它会。

bencyoung 于 2017-05-09

👍3

@FransBouma所以我们都应该因为企业想做愚蠢的事情而受苦吗？我不应该得到好东西，因为价值数百万美元的公共部门项目还没有准备好？这是如何运作的？

markrendle 于 2017-05-09

@markrendle想要继续工作代码有什么愚蠢的？

bencyoung 于 2017-05-09

👍7

他们选择 Java/JVM 是因为它没有与“快速移动”相关的所有缺点：它是一个稳定、可靠的平台，您的投资不会在 1-2 年内浪费掉。

而且您基本上可以永远使用 System.Web；它融入了 Windows，这意味着它可能永远不会消失。没有比这更稳定和可靠的了。

ASP.NET Core 1.x -> ASP.NET Core 2.x；所有 api 几乎相同，主要变化是放弃对 .NET Framework 的支持。它甚至会在休息时更改 semver 😱

ASP.NET Core 1.x 在 .NET Core 2.x 和 .NET Framework 上运行，支持 .NET Standard 2.x（通过 .NET Core 2.x）；并且具有与 ASP.NET Core 2.x 相同的 api，所以这是垫脚石版本。

ASP.NET Core 2.x 是中断版本。它仍然支持 .NET Standard 2.x（通过 .NET Core 2.x），并且 ASP.NET Core 1.x 和 ASP.NET Core 2.x 之间的 api 方面没有太大变化；但删除 .NET Framework。

benaadams 于 2017-05-09

👍8

替代方案可以是：

ASP.NET Core 继续朝着netstandard3.0 （可能是 2.x）之类的方向努力，并且只是更快地版本 netstandard。就像一个季度一次。
NetFx 下一个版本可能会再次跳转以支持netstandard3.x ，只要下一个版本是。它甚至不必是最新的标准。

这可能是个坏主意，因为使用的所有内容可能不需要成为 netstandard 的一部分，但至少 ASP.NET Core 2.x 将针对其他框架最终将使用的标准。

只是吐球。我确定这已经被提出来了。

adamhathcock 于 2017-05-09

👍3

@bencyoung我只是在暗示坚持整个世界都应该围绕你的 1500 万行 C# 代码运行有点自私（顺便说一句，这不会停止工作）。所以你不能使用 ASP.NET Core 2.0。您仍然拥有完整的仅限 Windows 的框架 ASP.NET，它具有通过它运行的传统支持，就像 Brighton through rock 一样。所以有一个你不能玩的新玩具，因为移植你的代码和重构/重构你的应用程序在经济上是不可行的。这很糟糕，但很多事情也是如此。但是，如果 Microsoft 避免所有不适用于已有 20 年历史的遗留代码库，这些代码库可能仍包含用 VB 6.0 编写的 COM 组件，那么再过 20 年，它们将成为 Micro Focus。

markrendle 于 2017-05-09

@adamhathcock这就是我认为netstandard 的用途-一种统一方法，而不是最小公分母。它可以随心所欲地移动，但它们将是 .NET 框架最终赶上的承诺。最终会有一个网络标准，基本上是 .NET 框架减去特定于平台的东西，然后统一起来

bencyoung 于 2017-05-09

NetFx 下一个版本可以再次跳转以支持 netstandard3.x，只要下一个版本是。

.NET Framework 更新是对地球上每台运行 Windows（大部分）的机器的强制更新。

.NET Core 更新是您为单个应用程序选择采取的更新。

他们是非常不同的野兽。

benaadams 于 2017-05-09

👍3

好吧，一个简单的事情是停止从ASP.NET Core 文档的第一页链接到该页面。

（或者干脆添加一行“如果你想继续使用 ASP.NET Core，就不要选择 .NET Framework！”。）

dahauns 于 2017-05-09

👍7 😄2

它们是 .NET 框架最终会赶上的承诺。

有https://github.com/aspnet/Home/issues/2022#issuecomment -299609207

我们的承诺一般是：如果类型在 .NET Framework 和 .NET Core 之间共享，我们打算将新添加的成员移植到 .NET Framework。在极少数情况下，这可能是不可能的，但关键是它们会被自动考虑。

但是当它赶上来的时候，ASP.NET 将转移到下一个 .NET Standard 版本，它永远不会是 ASP.NET 的 .NET Framework 的正确版本；它总是落后。

benaadams 于 2017-05-09

@markrendle不，它们不是大泥球。大混合并不意味着它们的架构不好。它们是模块化的。许多模块是很久以前由真正聪明的人编写或从第三方购买的久经考验的代码。有些是c的，有些是fortran的，有些是c++/cli的等等。要迁移或重写，我们需要了解它们，阅读论文，收集更多真实的测试数据，重新测试新版本。这需要努力，但这些任务从来没有预算，而是由我们自己决定。商务人士不在乎我们是否使用 .net 核心，但他们希望完成这些功能。对于第 3 方，我们必须敦促他们或寻求更换。
因此，在实践中可能需要几年时间。

qrli 于 2017-05-09

@benaadams

而且您基本上可以永远使用 System.Web；它融入了 Windows，这意味着它可能永远不会消失。没有比这更稳定和可靠的了。
ASP.NET Core 1.x -> ASP.NET Core 2.x；所有 api 几乎相同，主要变化是放弃对 .NET Framework 的支持。它甚至会在休息时更改 semver 😱
ASP.NET Core 1.x 在 .NET Core 2.x 和 .NET Framework 上运行，支持 .NET Standard 2.x（通过 .NET Core 2.x）；并且具有与 ASP.NET Core 2.x 相同的 api，所以这是垫脚石版本。
ASP.NET Core 2.x 是中断版本。它仍然支持 .NET Standard 2.x（通过 .NET Core 2.x），并且 ASP.NET Core 1.x 和 ASP.NET Core 2.x 之间的 api 方面没有太大变化；但删除 .NET Framework。

是的，让我们看看真正的选项是什么 :) ASPNET Core 1.x 是一个死胡同：你可以移植到那个，但如果你依赖于今天已满 .net 的库，你的代码就不能移动到 .net 核心，并且支持结束时可能不会移植到 .net core /standard。如果您的依赖项已经在 netstandard2.0/.netcore 上，那么现在选择 ASP.NET core 1.x 是明智的，那么您可以毫无问题地迁移到 asp.net core 2.x，因为您知道您并没有陷入死胡同。

如果您想获得稳定性，您选择 system.web 作为 nginx 和 JVM 堆栈的替代品的建议有点弱，您不觉得吗？ :) 这是关于大型组织选择什么作为平台的选项。除非他们正在创建一个全新的应用程序并且不必使用外部依赖项（很少见），否则他们可能会采取安全的赌注，为什么不呢？如果它归结为 system.web 或 JVM/nginx，则选择非常简单。

这是小事。之前锤过：sql server enterprise的加密特性。您不会在 .net 核心上使用这些，因为它们不存在。甲骨文？没有。所以如果你想使用asp.net core和这些功能，你必须使用.net full和asp.net core 1.x。但是，如果在对 asp.net core 1.x 的支持结束时这些功能无法移植/可用，会发生什么？（谁愿意在一个已经处于“QFE 模式”的平台上押注农场？）回到 system.web？

FransBouma 于 2017-05-09

👍1

在我看来，部分问题在于 ASP.NET 直接推动了 .NET Core 的发展。我想这是微软内部的事情，但平台和特定库实际上不应该如此紧密耦合。

如果某个新版本需要添加到 .NET 版本中，那么应该通过 netstandard bump（使用 vNext）将其提供给所有人，然后在发布时更新 ASP.NET 以使用它。我认为是 ASP.NET 的特权地位导致了这个问题。这可能是不可避免的，因为微软内部的开发人员群体是相同的......

作为大量使用 .NET 的 HPC 软件的作者，我们还实现了自己的零分配解析等，而无需更改底层平台。我们会从 Span 等中受益吗？绝对地！我们可以切换到 .NET Core 吗？很长时间没有。我们会看到将 Span 等添加到 .NET Framework 中吗？如果没有网络标准的承诺，现在似乎很难说......

bencyoung 于 2017-05-09

👍17

@markrendle当然可以，但是我们的过渡计划是什么？我看不到没有遇到不受支持的路径的人。如果更改是在 netstandard 中，然后 ASP.NET Core 使用它们，那么至少我们会知道最终会有一条路径......

bencyoung 于 2017-05-09

@markrendle我不确定谁是 asp.net 核心的目标用户。但我看到的大多是 .net 用户，他们对 .net 和大量遗留（不错）代码库进行了大量投资。如果我们不是目标用户，我看不到 node.js/python/go 家伙给 .net 一个 sh*t，无论我们认为 .net 有多好。
如果不是为了公司而是为了我自己的项目，我不会使用 asp，而是使用 nancy。企业需要稳定的保障和支持。他们/我们为此付出了大笔钱。

qrli 于 2017-05-09

这个问题的简单解决方案是，如果 Microsoft 制作一个仅适用于 Windows 的 CoreCLR 发行版，它支持全系列的 .NET Framework 库。

在我个人方面，在 ubuntu 的 PI 上玩 .NET Core 很酷，但业务方面甚至没有考虑 .NET Core，因为 .NET Framework 可以满足我们的所有需求，而 .NET Core 只是比较麻烦。大部分麻烦都在于工具和让每个人都设置好，所以这些痛苦终于消失了，但它仍然缺乏很多功能......也不能在 .NET Core 2 上运行。 SOAP 服务缺少 WCF（主机）是一个相当大的负担，因为它是我们整天在业务通信中所做的事情，但可能可以通过巧妙的设计和在多个应用程序中使用 .NET Core 和 .NET Framework 来缓解。 AppDomains 也不容易被替换，尽管那是我最不关心的问题。从 ASP.NET MVC 5 到 MVC Core 的飞跃对于重写来说出乎意料地容易，但使用 .NET Core 会使 VS 停止合作，显示所有错误。

在 WPF 中托管 ASP.NET Core 之类的有趣的事情也是不可能的。

Windows CoreCLR 发行版是否是封闭源代码甚至都没有关系，因为它与今天的 .NET Framework 没有太大区别。

现在请原谅我在悄悄地哭泣并删除迁移到 ASP.NET Core 的实验分支。

Suchiman 于 2017-05-09

如果您想获得稳定性，您选择 system.web 作为 nginx 和 JVM 堆栈的替代品的建议有点弱，您不觉得吗？

它的极端；）

如果它归结为 system.web 或 JVM/nginx，则选择非常简单。

是的，如果你可以使用 JVM，你可以使用 ASP.NET Core 2，因为你没有阻止程序，并且它有很好的互操作和 p/invoking :)

如果 api “几乎相同”，为什么不为所有版本保留一个 2x 的版本号，但可以选择“netstandard”或“netcore”？

因为它的内部结构正在发生变化；并利用对运行时、jit 和标准库的更改。对于用户来说，它们看起来与 ASP.NET 1.x 和 2.x 之间的兼容性大致相同；在暴露的 api 表面上，而不是内部“这就是它的完成方式”。

在我看来，部分问题在于 ASP.NET 直接推动了 .NET Core 的发展。

和其他人一样。您可以像我对 ValueTask 所做的那样，在dotnet/corefx发出 api 请求；然后演变成 Task-likes，现在是 C#7 的一部分。

一旦您的 api 包含在 .NET Core 中，您就可以开始使用它（如果您喜欢夜间活动并想确保 api 是正确的）；或者在 coreclr/corefx 的下一个版本，如果你想挂 6 个月。

然后 ASP.NET 更新以在它发布时使用它。

现在你必须等待2年。那不是很实用。因为 API 需要通过使用进行改进；并且通过使用会发生更多的发现。这就像在您的开发周期中添加一个 2 年的编译步骤。

作为大量使用 .NET 的 HPC 软件的作者，我们还实现了自己的零分配解析等，而无需更改底层平台。我们会从 Span 等中受益吗？绝对地！我们可以切换到 .NET Core 吗？很长时间没有。

您的 HPC 软件是否直接挂起 Web 请求？猜测它可能有由 webrequests 驱动的队列，但它在一个单独的进程中运行，所以应该不受这种变化的影响？

我们会看到将 Span 等添加到 .NET Framework 中吗？

是的

benaadams 于 2017-05-09

@benaadams

但是当它赶上来的时候，ASP.NET 将转移到下一个 .NET Standard 版本，它永远不会是 ASP.NET 的 .NET Framework 的正确版本；它总是落后。

如果至少有 1 个版本重叠（即，如果您使用最新的完整框架，那么仍然至少有一个官方支持的 (ASP).NET Core 版本在其上运行），这是完全可以接受的。

gingters 于 2017-05-09

👍1

Microsoft 将制作一个仅适用于 Windows 的 CoreCLR 发行版，它支持全部范围的 .NET Framework 库。

或一组 .NET Standard 2.0 库；所以他们可以在 .NET Core 上运行，而后者只能在覆盖 api 差距的 Windows 上运行？

benaadams 于 2017-05-09

👍4

@benaadams是的，这就是想法，尽管这不适用于抛出 PlatformNotSupportedException 的任何东西

Suchiman 于 2017-05-09

@qrli如果它是模块化的，那么您可以升级现在可以升级的模块，其余的留到以后。

除非“模块化”是指“它是一个庞大的单体 System.Web ASP.NET IIS 应用程序，包含通过 PInvoke 和 COM 互操作的数十个不同的库”，在这种情况下，这是一个大泥球。

markrendle 于 2017-05-09

👎8 👍1

是否有哪些程序集受到影响和哪些不受影响的最终列表？有人提到Microsoft.Extensions.*是安全的，并且Microsoft.AspNetCore.Razor.Runtime （假设）也是安全的，因此Microsoft.AspNetCore.Html.Abstractions也需要保持在netstandard上。 Microsoft.AspNetCore.*中还有其他东西留在netstandard上吗？

Kukkimonsuta 于 2017-05-09

@bencyoung我推荐的过渡计划是随着时间的推移将各种组件迁移到面向 .NET Core 2.x 的独立服务（或该特定组件的整个开发工具领域中最有效的服务），从您的旧代码中使用这些服务使用 HTTP 或消息总线的标准 API 边界，直到您拥有适当的分布式系统架构。

markrendle 于 2017-05-09

@markrendle 不过，并非所有东西都属于分布式系统。作为一个具体的例子：Stack Overflow 渲染页面如此之快的很大一部分原因在于它不是分布式的。虽然我们的网络延迟是 0.017 毫秒，但这会给我们的应用程序增加相当多的网络、序列化、反序列化和 GC 成本。将系统分片成许多服务并不是一个普遍的答案。这是一个复杂的，一个昂贵的，并且在许多情况下也是一个净负面因素。这可能是一件好事，但也可能是一件过于复杂的坏事。

NickCraver 于 2017-05-09

👍27 ❤6

@markrendle我的问题不是迁移到服务，而是一些基本的服务基础设施构建块使用的 API 不在netstandard20甚至netstandardbanana的路线图上。 .NET Core 对我们来说不是关于新建应用程序，而是关于整个新建系统。 System.DirectoryServices是一个例子，但对于其他人来说，它是 WCF，还有更多其他人，它是System.Data和 SqlClient 的东西，对于我们来说，是System.Messaging 。

如果可以，我完全赞成使用 .NET Core。到目前为止，这包括零客户项目，无论是否为绿地项目，它们都被阻止了。

jbogard 于 2017-05-09

👍16 😄1

@NickCraver我并不是要开玩笑或任何事情，而且我知道 SO 页面呈现如此之快的真正原因是您和其他构建它的人都很棒，但是包含指向您页面的链接的 Google 搜索结果渲染速度与您的页面一样快，而且您_知道_它们来自一个庞大而复杂的分布式系统。亚马逊页面呈现得非常快，同样的交易。我很乐观地认为 ASP.NET Core 正在朝着一个未来发展，在这个未来中，它可以以相同的方式构建系统，具有相同的性能，我认为如果它能够从完整 .NET 的小岛更新周期。

markrendle 于 2017-05-09

👍6

@jbogard我看到了类似的情况，但是当 .NET Core 2.0 推出时，情况会大不相同。

markrendle 于 2017-05-09

叹。

chadwackerman 于 2017-05-09

👍7

@jbogard

网标准香蕉

线程的报价

penderi 于 2017-05-09

😄13 👍1

对于我和我的团队来说，主要问题是没有迹象表明这条道路是预期的未来。我知道没有人知道未来，但听说我们需要将任何依赖于完整 .net 框架（组件供应商 dll、支付服务 sdks、HSM sdks）的东西分解到他们自己的服务中，并引入新的 hop STINGS。这不是这个网站需要的东西，现在我们必须要么引入更多的开发操作复杂性，要么将 Web 应用程序部分重新设计到 MVC 5。

我们选择了 asp.net core 来提高 kestrel 的速度和花哨的新 API。鉴于我们的依赖关系，如果能够更准确地权衡选项与缺乏简单的升级路径，那就太好了。

jabrown85 于 2017-05-09

👍18

添加到@jabrown85
到目前为止，ASP.NET Core 一直是情绪的过山车。
在 csproj 登陆后，我终于“准备好了”，并认为在其中启动任何新内容并检查可以升级的内容是不费吹灰之力的。在此公告之后，它更像是：“.NET Core 是否肯定支持该场景，还是我们应该安全并继续使用 MVC5？”

到目前为止，伤亡人数很少，只有一个用 ASP.NET Core 编写的应用程序管理主要 MVC 5 应用程序的管理任务，但由于主要应用程序使用 NHibernate，它将永远停留在 1.x 上。

Suchiman 于 2017-05-09

@markrendle电脑说不

如果有完整的 .NET -> netstandard 的路线图，那就太好了。 ApiPort 中的一些基本部分只是说“不支持”。我将对 ASP.NET Core 1.x 上的客户端项目进行更全面的分析，以查看缺少的内容。

jbogard 于 2017-05-09

但它将永远停留在 1.x 上，因为主应用程序使用 NHibernate。

不应该，NHibernate 没有死，是吗？

benaadams 于 2017-05-09

@benaadams出人意料地没有。它所做的一些事情是 EF6 确实没有任何等价物。我们默认使用 EF6，但在某些情况下我们必须走 NH 路线。

jbogard 于 2017-05-09

@benaadams正式不，它在似乎几乎死了的地方有暂停，但通常每隔几天就会有一次提交。 ApiPort 报告 .NET Standard 的覆盖率为 72.26%，但我不太相信它会被移植（至少在不久的将来）。

Suchiman 于 2017-05-09

阅读评论，我担心这个项目的总体方向。长期以来，ASP.NET 是一种稳定可靠的技术的不错选择。但是，我现在没有同样的感觉。有许多“快速行动并打破常规”的技术，但这是一个完全不同的类别。
我希望微软能够解决这些问题并符合每个人的期望。

这与企业与非企业软件无关。今天有很多 Python 2.x 应用程序在使用，但并不是所有的都是“企业”。更重要的是 - 并非所有新项目都使用 Python 3（在 Python 3.0 发布近 9 年后！）。

jvitkauskas 于 2017-05-09

👍10

任何人都可以在博客文章中总结整个线程吗？

我在通勤/午餐时通读了所有 300 多条评论，而且……我似乎仍然没有完全“明白”。

我得到的是：

.NET Core 2 不支持完整的 .NET Framework
每个依赖项都将依赖于netcoreapp2.0而不是netstandard2.0
如果我想要 DirectoryServices 或 Drawing 之类的东西，我需要删除 Full Framework 并跳转到 2.0

我有点错过了休息......繁忙的日程和一切。

MaximRouiller 于 2017-05-09

@MaximRouiller

如果我想要 DirectoryServices 或 Drawing 之类的东西，我需要删除 Full Framework 并跳转到 2.0

不，如果你想要一个不支持 .net core 的库，你将根本无法使用 AspNet Core 2.0+。

hikalkan 于 2017-05-09

@MaximRouiller ，他们刚刚所做的是 Asp.Net 核心项目将无法引用完整的框架程序集，这使得它对许多（如果不是大多数）来说毫无用处，他们说像 system.drawing 和 Directoryservices 这样的程序集将被移植到新的 netstandar或者我不知道，但是，除非有人移植旧程序集，否则它们将无法工作，因此，对于许多人来说，它几乎没有用，因为某些程序集是遗留的，永远不会被移植。总之，任何使用 .net core 和完整版 .NET 框架的人都被搞砸了，需要回到 MVC 5。

adrianlmm 于 2017-05-09

👍2

@davidfowl 顺便说一句，感谢您提供此列表。这是非常重要的“那么我们能从中得到什么？” 人们需要在脑海中平衡成本/收益的一块。

如果您还没有，请阅读列表，以便双方都了解情况。我仍然坚持希望 2.x 成为一个过渡版本（对业务有合理的好处以实际保证这一举措），而 3.x 是胜利所在。即使2天后出来。我真的很欣赏各方的洞察力。

NickCraver 于 2017-05-09

👍5

@davidfowl你说：

可以在标准之上编写库。当标准本身的内容需要更改时，将需要更长的时间才能在 .NET 的所有实现中采用，其中包括 .NET Framework。这可能意味着几件事：
.NET Standard 将以最慢的实现速度发展
.NET Standard 将以其他速度发展，而 .NET Framework 将是最后一个赶上的。

但为什么会这样呢？您不能发布 .NET Standard vNext 并让 .NET 在一段时间后（几个月到一年后）赶上它吗？这意味着处于最前沿并想要最新的 ASP.NET Core 的人可以在 .NET Core 中托管，而需要 .NET 的遗留代码的人最终可以在 .NET 赶上时使用该版本的 ASP.NET Core到它使用的 .NET Standard 版本。我不明白为什么 .NET Standard 必须与最低实现一样快。
同样在这里，我们谈论的是标准的官方实现，但还有其他实现不会与标准同步更新。
这样你就不会留下人。当然，如果它们在 .NET 中，它们需要更长的时间才能从最新功能中受益，但它们不会永远停滞不前。

jdom 于 2017-05-09

👍13

@jdom ，因为我知道 .NET Framework 更改的速度以及为什么它必须变慢。这是一个不同的分布，也许没有足够的欣赏。任何更改都会被推送到数十亿台机器上。分层也是完全不同的，所以这不是一件微不足道的事情。

我不明白为什么 .NET Standard 必须与最低实现一样快。

如果我们在 ASP.NET Core 中不断提高 .net 标准的低水位线，它就达不到目的，让您处于同样的境地。当然，您不会感到被抛在后面，因为有人承诺有一天这些 API 会出现在 .NET Framework 中，但是会在什么时间线出现？ .NET 4.7 仍未完成与 .NET Standard 2.0 的功能对等。

davidfowl 于 2017-05-09

@davidfowl但这会带来与 PCL 相同的问题，它将成为最低公分母并且使用起来很痛苦，ASP.NET 放弃使用它的事实已经表明了这一点。

Suchiman 于 2017-05-09

@davidfowl但这会带来与 PCL 相同的问题，它将成为最低的公分母并且使用起来很痛苦，

@Suchiman这是怎么回事？ PCL 的唯一问题是它们是如何在 NuGet 中动态计算和表示的，这使得很难预测你会得到什么。如果 netstandard 不是可以由不同实现实现的 API 集，它还能如何工作？

让 PCL 使用起来很烦人的是超级小 API 表面积。 .NET Standard 1.3-1.4 足以明智地实现大多数基本库 API。

.NET Standard 始终关注广度。

ASP.NET Core 和 .NET Core 是关于用于构建轻量级微服务的具有竞争力的跨平台服务器堆栈。从这个意义上说，呼吸是更广泛的平台支持（在 linux、osx、tizen、pi 等上运行）。

davidfowl 于 2017-05-09

👍2

@davidfowl

我们已经将字符串确定为我们希望在 .NET Core 中尝试解决的主要问题之一，有很多想法，但其中之一是默认将字符串设置为 utf8（大量兼容问题，但请在此处关注我）。

我们想要修复的另一件事是能够获取廉价的数组/字符串切片，任何连续内存。我们添加了跨度并且正在查看缓冲区来代表这一点。这可能意味着 String 和 Array 实现了新的接口，使获取需要 0 分配的切片成为可能。

听起来这意味着如果我想在库中使用这些新位，库还需要定位netcoreapp2.0而不是netstandard2.0 。那是对的吗？

danielcrabtree 于 2017-05-09

👍1

不再支持旧的 4.x 框架是一个非常糟糕的主意。如果它导致大量工作，人们不会升级。请参阅自 2002 年以来已弃用的超级经典 ASP - 大约 15 年。而且我们还有经典 ASP 中仍然存在的旧应用程序！微软愿意再次看到类似的东西吗？放弃旧的 4.x 支持是必须要做的事情 - 但从长远来看！现在不要。几年后，当 .NET 核心成为事实上的标准并且只有旧应用程序使用 net 4.x 时，这可能是一个选项。

(ASP).NET Core 背后的想法真的很棒，这是微软自 .NET 发布以来所做的最好的事情。但是这样的混乱使这个美好的概念变得迟钝。同样非常可悲的是，微软自己决定了如此巨大的变化，甚至没有在社区中讨论它！似乎这家公司还没有完全学会如何处理开源项目。

DMW007 于 2017-05-09

👍1

@davidfowl

.NET Standard 始终关注广度。

API 或平台的广度？

以与.netcoreapp相同的速度发展.netstandard有什么问题？
是否有任何 BCL 调整目标特定于.netcoreapp ，因为它们永远不会在其他框架中实现？

与.netcoreapp2.1同时发布.netstandard2.1与先发布.netcoreapp2.1和一年后发布.netstandard2.1与.net50同时发布没有区别.netstandard2.1目标的软件包将在.net50上立即开始运行，但如果它们以.netcoreapp2.1目标，则会被阻止

Suchiman 于 2017-05-09

👍6

ASP.NET Core 是一个建立在 .NET Core 之上的高级 webapp 框架，未来将面向 .NET Core，_然而_ 它也可以是一个构建在 .NET Standard 之上的高级 webapp 框架，因此它的目标是参考 API 接口，而不是它的特定实现。

.NET Standard 的公共定位是一个易于构建的目标，同时将实现细节搁置一旁 - 直接来自 Microsoft 的 2 个官方框架涵盖了大多数用例。

为什么现在改变这个故事？ 如果 .NET Framework 永远赶不上，那似乎是无关紧要的。至少它有可能这样做，或者另一个第 3 方框架可以这样做。那么，如果只有一个实现能够真正跟上步伐呢？这就是为什么即使只有一个具体的实现，我们的应用程序中也有接口的原因，这样我们就有了它带来的灵活性和优势。

也许缩小 ASP.NET Core 2.0 与 .NET Standard 2.0 内联的范围，然后将 .NET Standard 2.1 用于更新功能？加上一些体面的支持时间表，这难道不能解决整个困境吗？微软拥有 .NET Standard 和这两个框架，所以这种对递增版本的担忧似乎完全没有根据......

manigandham 于 2017-05-09

👍5

我想应该考虑到 ASP.NET 到 ASP.NET Core 并不是每个人的迁移路径。

完整框架上的 ASP.NET 将保留并获得功能，但不像 Core。

随着时间的推移，迁移会变得更容易，但绝不会是 100% 匹配。

人们仍然运行经典的 ASP。这对他们也很好。

adamhathcock 于 2017-05-09

👍3

@davidfowl我非常尊重整个团队以及你们所取得的进步。所以，请不要认为这是对正在发生的事情的失望。你们是开拓者，我们都以你们为榜样，说明如何正确地做事。但我不认为其中很多点是直接的目标变化问题，尤其是在没有沟通的情况下。也许我错了。

我想在这里抛出一些疯狂的东西，因为它已经被提到过几次了。我要说的与会发生什么无关，现在都是猜测。有几个人问我们为什么要针对 .NET Core 而不是 .NET Standard。
我们已经将字符串确定为我们希望在 .NET Core 中尝试解决的主要问题之一，有很多想法，但其中之一是默认将字符串设置为 utf8（大量兼容问题，但请在此处关注我）。

这一点肯定会改变游戏规则，但 IMO 是唯一一个绝对不需要定位框架的，而且无论如何它都不适用于 netcoreapp20。

我们想要修复的另一件事是能够获取廉价的数组/字符串切片，任何连续内存。我们添加了跨度并且正在查看缓冲区来代表这一点。这可能意味着 String 和 Array 实现了新的接口，使获取需要 0 分配的切片成为可能。
这导致 String 上的新方法允许拆分而不是每次都分配数组。
这会导致采用 Span 的 Int、UInt 等 (TryParse) 的重载和跨度.
这导致了采用 Span 的新编码例程.
缓冲和跨度让您以统一的方式表示内存，我们希望升级网络堆栈以允许传递占用 Span 的预固定缓冲区或缓冲区.

所有这些仍然可以作为当前网络标准之上的包来实现。你甚至不需要 netstandard20 。我知道不想随身携带这个包袱，但是当用例或性能不适合时，我们其他人在非 MS 世界中必须始终创建自定义的 BCL 式 impl。更不用说 Span API 也不是针对 2.0 的（除非再次更改）。

Kestrel 将在 2.x 时间范围内实现 HTTP2（目前针对 2.1），这需要 SSL 流上的新 API 来执行 ALPN（https://en.wikipedia.org/wiki/Application-Layer_Protocol_Negotiation）。
.NET Core 上的 Http 客户端支持双工流式传输，它可以通过单个非 websocket http 请求在信号器中通过 http 实现流式传输端点。

我觉得这个有点棘手，但与 Kestrel 携带 libuv 并没有什么不同。 .Net Core 的 CURL 实现可以很容易地被拉入一个 netstandard 扩展包，直到每个人都赶上来。

我们从 HttpClient 和 System.Net.Http 分叉了标头解析器实现并将它们重命名（https://github.com/aspnet/HttpAbstractions/tree/d1d9bceff56cb44a194ae36923ce687e5e353006/src/Microsoft.Net.Http.Headers），以便我们可以改进它们并让它们同时支持 .NET Framework 和 .NET Core。 .NET Core 有一份这些改进的副本，因为没有必要改进它们（我们无法使用它们），所以没有恢复。

是的，但在这种情况下，这可以说是正确的做法。等待并坚持实现令人沮丧，但是我看不出这与其他人在编写框架或库时所做的有什么不同。

如果没有修改核心原语的能力，我们鼓励将它们分叉并制作看起来像它们但不是它们的东西。这就是我们在 ASP.NET Core https://github.com/aspnet/Common/tree/dev/src/Microsoft.Extensions.Primitives 中拥有自己的小 BCL 的原因。

再次，就像我们其他人一样。

ASP.NET Core 和 .NET Core 是关于用于构建轻量级微服务的具有竞争力的跨平台服务器堆栈。

ASP.Net Core 有一些类似的消息传递。 .Net Core 从第一天起就被宣传为功能齐全的 xplat 服务器端 .Net 框架子集。我从未听过任何人说 .Net Core 仅适用于微服务。我听说您可以根据需要将其与 ASP.Net Core 一起使用，还可以将其与控制台应用程序、数据分析、数据库服务等一起使用。.Net Core 的方向是否有效地“无论 ASP.Net Core 团队最想要什么”？

完整框架上的 ASP.NET 将保留并获得功能，但不像 Core。

会吗？我还没有看到来自 MS 的任何人确认它仍在进行中。我的直觉告诉我不是。我知道了。团队需要一个“不走就走”的时刻来挣脱。我只是不认为这是那个时刻。

mattnischan 于 2017-05-09

👍1

假设我们有一个业务逻辑 4.6 程序集，它使用 Oracle.Net 驱动程序、NHibernate 和 RabbitMQ（它们都在 4.6 中）。与 ASP.Net 的接口仅通过我们的业务对象、请求和响应。我们可以在我们的 ASP.Net Core 2 中引用这个程序集，而不需要重新编译吗？

stefan2410 于 2017-05-09

我的快速总结
aspnetcore

arkadiuszwojcik 于 2017-05-09

👎25 😄12 👍2

@stefan2410简短回答，不，您不能引用完整的框架，只有在为 netstandar 2.0 创建时才能引用这些程序集。

adrianlmm 于 2017-05-09

@mattnischan

所有这些仍然可以作为当前网络标准之上的包来实现。你甚至不需要 netstandard20 。我知道不想随身携带这个包袱，但是当用例或性能不适合时，我们其他人在非 MS 世界中必须始终创建自定义的 BCL 式 impl。

我很抱歉，但事实并非如此。你不能猴子补丁类型。除非您建议我们添加新类型并且不要更改现有类型。

更不用说 Span API 也不是针对 2.0 的（除非再次更改）。

Span 作为实现存在于 2.0 中，但不是公共 API。我们在新专业中进行了重大更改，以便我们可以在次要版本中提供更多功能。如果 ASP.NET Core 2.1 以 .NET Standard 2.1 为目标，则再次删除 .NET Framework 支持。

我觉得这个有点棘手，但与 Kestrel 携带 libuv 并没有什么不同。 .Net Core 的 CURL 实现可以很容易地被拉入一个 netstandard 扩展包，直到每个人都赶上来。

所以你说的是我们应该重命名 BCL 中的所有类，以便我们可以在两个 .NET Standard 上使用它们。

我从未听过任何人说 .Net Core 仅适用于微服务。我听说您可以根据需要将其与 ASP.Net Core 一起使用，还可以将其与控制台应用程序、数据分析、数据库服务等一起使用。.Net Core 的方向是否有效地“无论 ASP.Net Core 团队最想要什么”？

不，.NET Core 是一个通用框架，其核心最初没有垂直领域。可能 ASP.NET Core 应该只是一个垂直而不是 .NET Core 之上的库，它可能会避免一些这种混淆。

会吗？我还没有看到来自 MS 的任何人确认它仍在进行中。我的直觉告诉我不是。我知道了。团队需要一个“不走就走”的时刻来挣脱。我只是不认为这是那个时刻。

是的，在上一个版本中添加了 HTTP/2 支持。还有另一个团队在 ASP.NET 和 IIS 上工作，他们确实进行了改进。但是，它们的规模与 ASP.NET Core 所做的不同。

davidfowl 于 2017-05-09

我对此没有很强烈的感觉，因为我避免在像瘟疫这样的完整框架上运行我的 ASP.NET Core 服务。话虽如此，我不得不避免使用一些不错且成熟的库，因为它们不支持 .NET Standard，因为它们要么在等待netstandard2.0 ，要么只是因为它们不想这样做。

我担心删除在完整框架上运行 ASP.NET Core 的能力会阻止用户将他们当前的 MVC 5/Web API 2 应用程序移植到 ASP.NET Core，这将为库作者提供另一个避免移植到 .NET 的理由标准。如果您的用户都不会受益，为什么还要费心进行工作升级？它变成了先有鸡还是先有蛋的问题，我只是担心这会损害整个生态系统，就像它开始获得一些牵引力一样。首先，您需要 ASP.NET Core 用户，但我不相信会有我们所有人想要的那么多。希望我错了。

ericl85 于 2017-05-09

👍4

如果 ASP.NET Core 2.1 以 .NET Standard 2.1 为目标，则再次删除 .NET Framework 支持。

不，这只是意味着 Net Framework 将在支持 .NET Standard 2.1 时自动支持 ASP.NET Core 2.1，无论何时，即使需要一两年时间。

对于所有其他符合 .NET 标准的平台（Xamarin / Unity / ...）也是如此。

在 .NET Standard 上构建意味着其他平台将_最终_点亮，在 .NET Core 上构建意味着它们将_never__点亮。

我假设计划仍然是 full-fx 将赶上 netstandard，即使延迟很长？
（如果除了 NET Core 之外没有其他平台有望实现 .NET Standard 2.1，那为什么还要有 .NET Standard？）

0x53A 于 2017-05-09

👍19

我很抱歉，但事实并非如此。你不能猴子补丁类型。除非您建议我们添加新类型并且不要更改现有类型。

后者是 1.x 中大多数情况下已经完成的，对吧？是不是一下子就站不住脚了？

Span 作为实现存在于 2.0 中，但不是公共 API。我们在新专业中进行了重大更改，以便我们可以在次要版本中提供更多功能。如果 ASP.NET Core 2.1 以 .NET Standard 2.1 为目标，则再次删除 .NET Framework 支持。

为什么会被丢弃？你是说 Span _never_ 会出现在 Framework 上吗？

所以你说的是我们应该重命名 BCL 中的所有类，以便我们可以在两个 .NET Standard 上使用它们。

哇，没有。我的意思是，如果我需要一个具有不同 API 的字典，我必须创建其他东西，并且不能将其命名为 System.Collections.Generic.Dictionary，就像你们对 Microsoft.Net 所做的一样。*

是的，在上一个版本中添加了 HTTP/2 支持。还有另一个团队在 ASP.NET 和 IIS 上工作，他们确实进行了改进。但是，它们的规模与 ASP.NET Core 所做的不同。

这还算公平。我没有意识到这一点。

mattnischan 于 2017-05-09

后者是 1.x 中大多数情况下已经完成的，对吧？是不是一下子就站不住脚了？

它会造成混乱。他们试图尽可能少地这样做。我认为，API 设计和部署比大多数人意识到的要复杂得多。并不是微软的人这样做，而是支持许多平台和时间线的现实。直到我多次参与其中并谈论所有事情时，我才意识到这一点。不过，我真的希望类型转发是在方法级别。到目前为止，它已经解决了很多案例:(

为什么会被丢弃？你是说框架上永远不会存在 Span 吗？

它需要从 ASP.NET Core 2.0中删除，因为时间线不再对齐，因为完整的框架还没有它。

NickCraver 于 2017-05-09

它需要从 ASP.NET Core 2.0 中删除，因为时间线不再对齐，因为完整的框架还没有它。

AFAIK，跨度是可在 .NET 桌面上使用的netstandard1.x包的一部分（它是一个可移植的实现，因此它没有与支持到 CLR 中的相同的性能提升，但很可能够好了）。

编辑： System.Memory包有一个netstandard1.0 TFM，所以它甚至可以在 .NET 4.5 上使用。

kevinchalet 于 2017-05-09

后者是 1.x 中大多数情况下已经完成的，对吧？是不是一下子就站不住脚了？

因此，我们今天停止了某些方向的功能工作。这是故意的，我们通过复制和重新实现 .NET Standard 之外的东西来拒绝使用新的 API，以便 .NET Framework 可以工作。这还不是全部，但我们希望在未来触及一些基本的部分，毕竟我们（微软）控制着双方。

为什么会被丢弃？你是说框架上永远不会存在 Span 吗？

Span 本身有一个可在任何地方运行的便携式版本，我不确定快速实现是否会在 .NET Framework 上。将添加到利用 Span 的 .NET Framework 的 API 可能需要比Span 本身更长的时间，它非常广泛。我们最后一次在 .NET Framework 中更改字符串和数组是什么时候？

哇，没有。我的意思是，如果我需要一个具有不同 API 的字典，我必须创建其他东西，并且不能将其命名为 System.Collections.Generic.Dictionary，就像你们对 Microsoft.Net 所做的一样。*

这正是你所建议的。我们不想拥有 Microsoft.Extensions.Collections.Generic。我们尽量避免这种情况，并且尽可能使用旧的 API 和 polyfill（https://github.com/aspnet/DependencyInjection/blob/139d91e57dd31fcd5c6ddaf11ad1f771b5855807/src/Microsoft.Extensions.DependencyInjection/Internal/ConcurrentDictionaryExtensions.cs）。这是不可持续的，这意味着 .NET Core 没有获得好处，因为我们积极避免使用它。

davidfowl 于 2017-05-09

👍1

@PinpointTownes具有跨度还不够好，他们需要在对现有类型的方法调用中使用它们。这就是类级别类型转发发挥作用并引起许多问题的时候。

NickCraver 于 2017-05-09

@0x53A

这还算公平。你能告诉我为什么 NuGet 上的流行库不放弃对明显不支持的旧 .NET Framework 版本的支持吗？最流行的库针对 net20、net35、net40 等。为什么突然需要最高版本的 .NET Framework 才能继续使用 ASP.NET Core？你认为这合理吗？

davidfowl 于 2017-05-09

👍2

这是一个表演停止者。我必须考虑取消从 ASP.NET MVC 5/Web Api 2 到核心的迁移。许多稳定的框架还不能用于核心。我们仍在使用 EF6.x，因为 EF Core 还不够成熟功能比较。

schonbachler 于 2017-05-09

👍1

@PinpointTownes具有跨度还不够好，他们需要在对现有类型的方法调用中使用它们。

“需要”可能有点过分。 Spans 主要用于提高性能，因此在 .NET Desktop 获得对 Spans 的本机支持之前，没有什么能阻止他们使用 ifdefs 在 .NET Desktop 上使用现有的非超级性能重载。

kevinchalet 于 2017-05-09

👎2

@davidfowl我认为最大的问题是情绪化。如果您以 netstandard 为目标，我知道我最终能够从 1.x 升级到 2.x（即使有延迟）。大多数时候，更新 netfx 对应用程序来说并不是什么大不了的事（对于 lib 不同）。

但是有些应用程序永远无法跳转 netfx -> netcore，所以如果你以 netcore 为目标，他们知道他们在 1.x 中处于死胡同。

在这方面，如果 Asp.net 核心从未在 netfx 上运行会更好，因为他们希望这种情况继续下去，现在感觉（理所当然地，IMO）被背叛了。毕竟，他们可能已经在这方面投入了大量时间。

我个人并没有对此进行投资，因为我不是 asp.net 用户，我的大问题实际上只是

我假设计划仍然是 full-fx 将赶上 netstandard，即使延迟很长？
（如果除了 NET Core 之外没有其他平台有望实现 .NET Standard 2.1，那为什么还要有 .NET Standard？）

关于其他针对 net20、net35 等的库，根据我的经验，大多数作者都试图针对他们可以使用的最低版本，并且只削减他们别无选择的平台。

__是的，我认为放弃对旧版本 .NET Framework__ 的支持是合理的，因为仍然有一个明确的迁移路径可用。只需更新您的版本。大多数时候，您甚至不需要更改任何内容，“只需”重新编译和测试。

我认为你们严重低估了永远无法以 netcore 为目标的应用程序的数量——仅仅一个封闭源代码的第三方依赖就足以阻止它。

0x53A 于 2017-05-09

👍4

Span 本身有一个可在任何地方运行的便携式版本，我不确定快速实现是否会在 .NET Framework 上。将添加到利用 Span 的 .NET Framework 的 API 可能需要比 Span 本身更长的时间，它非常广泛。我们最后一次在 .NET Framework 中更改字符串和数组是什么时候？

@davidfowl我认为这可能是问题的一部分。老实说，我在这里有点扮演魔鬼的拥护者，因为我们被困在中间，因为我们只是在 .Net Core 出现之前就开始了的新应用程序，所以我们跨界了。

我们的想法一直是，尽可能使用花哨的新库（例如 Kestrel），但等待 .Net Core 稳定下来（我很高兴我们做到了，如果只是为了工具更改）， _or_等待酷酷的核心位使其回到框架。我认为大多数人的假设是，即使不是全部，corefx 所做的大部分（如果不是全部）进步都会使其进入 Framework vNext 或 vNext+1。但是，从这个和其他变化看来（从我们 30k 英尺的角度来看）Framework 不是未来的平台。

我想如果是这样的话，那就是这样。我们的项目非常庞大，所以请相信我，当我说我确实理解拥有一堆与 BCL 类型或 ifdef spaghetti 接近但不完全一样的自定义 impl 的东西时的痛苦。因此，我并不是出于对并发症的无知而提出建议。肯定有权衡。

mattnischan 于 2017-05-09

确实是一个好问题：将 .net 核心功能向后移植到 .NET full 还剩下什么？正如我在这里所读到的，.NET full 非常脆弱，将代码移动到它需要很长时间（它移动非常缓慢）并且随时可能中断（可能，不知道它是如何交织在一起的）所以我得出结论，这不会发生常常。

不能两者兼得：要么完全向后移植到 .NET，要么发布频率较低（例如每 6 个月到一年），要么非常复杂且容易出错。如果是前者，那就加快步伐，不要让你的用户买单，停止以后者为借口。如果是后者，那么 netstandard 是一个谬误的结论是不是正确的，因为对未来而言，无论如何，.netcore 的 API 才是最重要的？

我非常担心.NET 未来的发展方向。我的公司为 .NET full 和 .NET standard1.6 构建工具。我们最不想要的是 .NET 方向的驱动力（即将完全向后移植到 .NET 的新功能，正如所有这些卫星之前的 .NET 核心公告中所说）有效地分裂事物和生态系统被分成两半，因为碎片正在杀死。

此线程中的任何内容都无法让我放心，对于 _all_ .NET 的未来以及使其保持活力所需的生态系统而言，一切都很好：我只看到两组：

担心选择变得复杂并且他们面临着棘手问题的人
微软看到了一条前路：.net 核心之路。

这两个暂时不匹配。 Microsoft 的某个人能否提供一个连贯的故事，以便我们所有人都能看到真正的交易，事情的真实情况，即将功能向后移植到完整的 .net，如何处理 .net 核心中丢失的无数东西（sqlserver 的东西，事务范围等等）以及微软如何认为他们可以将这个新方向作为一个可靠的、可靠的、可靠的平台出售给未来，因此企业和大型团队可以放心地选择它。

FransBouma 于 2017-05-09

👍23

虽然我同意所有这些从长远来看都是一件好事，但我也认为放弃对 2.0 完整框架的支持还为时过早。

我们希望尽快迁移到 .NET Core，但不幸的是，我们现在最大的障碍几乎完全是Microsoft 库（例如，Entity Framework Core 还不够好，Azure Service Bus 只有一个非常早期的预览版）。

虽然我希望 Azure 库将在接下来的几周/几个月内准备就绪，但 EF Core 似乎不会很快拥有足够的功能。

我对 EF6 的内部结构一无所知，但是通过合理的努力使其以 netstandard 为目标是不是不可能的？这将删除一个巨大的障碍...

“仅仅停留在 1.x”似乎不是一个好的选择，因为肯定会有很多库不在乎（或者没有资源/知识来支持两者），只是将它们的依赖升级到2.0

PS：我对 .NET 生态系统在过去几年变得如此复杂感到非常沮丧。我不得不花费大量时间来了解所有新内容，但我不知道新开发人员应该如何理解其中的任何内容。由于所有这些非常极端的重大变化，现在互联网上有太多过时的信息。
此外，所有不同的产品版本（.net core、sdk、.net standard，...）都非常令人困惑。我还没有看到不需要 20 分钟解释就能理解 .NET 标准表的人。 😞

cwe1ss 于 2017-05-09

👍13

任何使用 .net core 和完整版 .NET 框架的人都被搞砸了，需要回到 MVC 5

是的。我理解其中的原因，我想我可以说我应该预见到这种情况的发生，但是在没有事先警告的情况下将其落到我们身上是非常令人沮丧的。

我们有一个应用程序生态系统，与许多其他系统一样，共享库可以追溯到十多年前，多个 MVC 3、4、5 应用程序、控制台应用程序、Windows 服务、数十万行代码。与某些人相比，我们甚至没有那么糟糕的升级情况。

我们最近使用 ASP.Net Core 1.1 建立了几个新的 Web 应用程序，它们必然针对完整的 4.6.2 框架。这些应用程序使用我们现有的大量共享库。我们在处理 project.json，然后是新的 .csproj 上花费了令人尴尬的开发时间，试图在同一个解决方案中混合新旧 .csproj，回到 VS15 以使用旧的 .csproj 类型完成工作，坏了系统。依赖关系，以及一连串的程序集绑定问题，构建和发布问题..这个列表还在继续。

现在，我们被悬在死胡同里。我们是否放弃了几个月的开发工作，还是花费了很多次尝试首先确定哪些可能有效，哪些可能无效，然后找出任何升级方法，然后如果可能的话就去做。

我不能说我不同意它的方向和必要性，但早期的沟通将不胜感激。

qstarin 于 2017-05-09

👍2

哦，当然，Azure Service Fabric 库也不在 .NET 核心上运行——这对我们来说是另一个障碍。

我会说您应该支持完整的 .NET 框架，直到您可以在 Microsoft（尤其是 Azure）中提供适当的 .NET 核心故事。

cwe1ss 于 2017-05-09

👍13

@cwe1ss 不过，此更改将降低 .NET 生态系统的一些复杂性。因为您不会有两种不同的格式（ASP.NET Core + .NET Full 和 ASP.NET + .NET Core）。我完全同意这些过时的信息，但我认为当你像微软现在所做的那样公开开发时，这是无法避免的。

Rutix 于 2017-05-09

@davidfowl

跨不同 .NET 运行时的代码共享故事是 .NET Standard。您的库应尝试将其定位为跨 .NET Core 和 .NET Framework 共享的代码。<

但据我所知，完整的框架甚至不支持.net 标准，所以它真的不是一个有用的标准。

微软似乎忘记了向后兼容的重要性。<<

问题是，ASP.NET Core 从来都不是向后兼容的……这就是为什么从 ASP.NET 4.x 出现如此大的范式转变的原因。似乎向后兼容性是您最好在 .NET Framework 上使用 ASP.NET 4.x 的高阶位。这在可预见的未来受到支持，只要 Windows 还活着，就会得到安全补丁。<

安全补丁只是问题的一部分。 Web 标准变化如此之快，以至于我们需要一些可以使用最新标准的东西。因此，例如，我在上面的某个地方看到了有关 HTTPS v2 的内容。我不知道这在实践中意味着什么，但关键是我希望我的框架能够支持这些东西。如果我被迫使用旧版本的框架，无论是 v4 还是 v1，它都不会支持所需的东西。

ASP .net Core 一直被宣传为在 .net core 和框架上运行。正如其他人所说，如果我们必须等待六个月或一年直到框架赶上来，我不会打扰。无论如何，我通常落后大约六个月或更长时间。但似乎正在发生的事情是，我们现有的投资正在被完全放弃，就像我们许多人投入时间的许多其他 Microsoft 技术一样。

斯特凡

stefanolson 于 2017-05-09

@Rutix表示“公开开发”，这个重大的突破性变化在没有任何公告或调查的情况下出人意料地完成了（毕竟，这个问题是由社区成员观察拉取请求创建的）。

过去默默地做事已经咬了微软，他们似乎没有学习。甚至不要试图告诉我他们看不到放弃完整的框架支持会扰乱社区并损害对平台的信心和投资。

最后一个事件是https://github.com/dotnet/roslyn/issues/17054但他们很快纠正了它，我想知道这将如何结束。

Suchiman 于 2017-05-09

👍5 ❤4

但据我所知，完整的框架甚至不支持.net 标准，所以它真的不是一个有用的标准。

@stefanolson那是不正确的。面向 .Net Standard 1.x 的库现在可以在各种完整的框架版本上运行。我上次查看的针对 .Net Standard 2.0 的库预计能够在 4.6.1 上运行。

mattnischan 于 2017-05-09

@Suchiman我完全同意你的看法。我有点失望，他们似乎没有学会如何沟通和向社区投掷炸弹。如果他们先宣布并进行社区讨论，他们本可以更好地处理这种方式。

Rutix 于 2017-05-09

但据我所知，完整的框架甚至不支持.net 标准，所以它真的不是一个有用的标准。

@stefanolson确实如此。不同（现有）版本的 .NET Framework 实现不同版本的 .NET 标准。请参阅https://blogs.msdn.microsoft.com/dotnet/2016/09/26/introducing-net-standard/

khellang 于 2017-05-09

我知道我对这个线程有点晚了，但这里有两个在 Windows 上的 NetFX 上使用 ASP.NET Core 的用例：

使用 ASP.NET 为您的应用程序托管 REST API

我们的应用程序是一种“.NET API 转换为 REST API”的应用程序。它最初是作为 .NET API 发布的，并且依赖于各种 Windows 的东西。

添加 REST API 时，我们选择 ASP.NET Web API 来托管它。当 Web API 明确统一在 ASP.NET vNext/5/Core 中时，__and__ 我们发现 __ASP.NET Core 将在 NetFX__ 上运行，因此使用 ASP.NET vNext/5/Core 是有意义的。

虽然我们利用 .NET Core 将我们的应用程序（部分）移植到 Linux 和 macOS，但仍有一些 Windows 依赖项不在 .NET Core 上运行（要获取我们移植的依赖项列表，请查看CoreCompat.* NuGet 包）。

长话短说，我们现在发现自己锁定在 ASP.NET Core 1.x 上，它将在有限的时间内保持支持。然后什么？回到 ASP.NET 4？

我了解您正在做的所有性能工作并在 .NET Core 的其他领域推动边界，但在我的用例中，我不是托管一个大容量的互联网公开网站，而是托管一个 REST API，它将怎么样，最大 10-20 RPS？

视觉工作室支持

确实，我在 NET 4.x 上的 Visual Studio 2017 体验仍然比 .NET Core 好得多 - 一个很好的例子是重新编译测试项目并让新测试显示在测试窗口中所需的时间. 在 NetFX 上速度要快得多。

我们最终会遇到这样一种情况，即今天我们有一个 NetFX 和 .NET Core 项目并排编译基本相同的代码库。我们保持这种双重维护的唯一原因是因为 Visual Studio 在 .NET Core 项目中的性能（_尤其是_单元测试和调试器）。

事后才想到，真正让我印象深刻的是，这个改变是现在做出的，比预览版早了几天。这似乎表明还没有技术上的理由这样做 - 那么为什么不在 ASP.NET Core v3 中进行更改呢？

qmfrederik 于 2017-05-09

👍1

@mattnischan

@stefanolson那是不正确的。面向 .Net Standard 1.x 的库现在可以在各种完整的框架版本上运行。我上次查看的针对 .Net Standard 2.0 的库预计能够在 4.6.1 上运行。<

在我看来，asp.net core 将运行 .net core 而不是 .net 标准？所以我仍然不确定.net 标准的意义是什么——如果它在创建后几乎就被放弃了。

如果 asp.net 核心需要 .net 标准 2.1，那将是完全有意义的，因为他们需要的东西目前不在框架中。因此，我们必须等到完整的 .net 框架支持这些附加功能，才能使用最新版本的 Asp.net 核心。那会奏效并且有意义。

但是相反，他们只是放弃了标准，使标准无用（如果我正确理解了这种令人困惑的情况）

stefanolson 于 2017-05-09

👍1

所以……它的 Build 2017 从明天开始；我想团队正忙于为此做准备。也许有一些公告，也许没有。也许，给他们一点喘息的空间，然后在一周内重新开会？

也许赶上节目https://build.microsoft.com/ （太平洋标准时间周三 8:00，格林威治标准时间 15:00 和周四类似？）

我们可能知道更多；不得。事情可能更清楚，也可能不会。但是，ASP.NET 团队可能会做出更好的回应，并更多地关注每个人的关注点。虽然@davidfowl一直在勇敢地做！

benaadams 于 2017-05-09

👍24

@stefanolson但是相反，他们只是放弃了标准，使标准无用（如果我正确理解了这种令人困惑的情况）

我认为 .NET Standard 的重点是兼容性。库作者可以针对 .NET Standard，然后任何人都可以使用它，无论他们使用的是 .NET Framework、.NET Core 还是其他支持 .NET Standard 的东西。

我认为 .NET Core 的意义在于重新构想 .NET Framework。 .NET Core 是跨平台、高性能、开源且快速发展的。

默认情况下将 string 的实现更改为 utf8 是巨大的，而不是您期望在 .NET Framework 上看到的内容。

看完这篇文章，我觉得：
.NET Core -> .NET Framework 就像 ASP.NET MVC -> WebForms。

danielcrabtree 于 2017-05-09

我也想支持工具方面。当前的还原/构建/测试等性能非常糟糕，而且非常痛苦。如果我们必须“停留在 1.0”上，我们是否仍然能够使用具有（希望）更好性能的新 SDK，还是会被 1.x SDK 卡住？

cwe1ss 于 2017-05-09

.NET Core 的故事是一个充满跌宕起伏的精彩旅程。我们最近才开始在 ASP.NET Core 上工作，因为之前的所有“搞砸”（版本控制、命名、project.json - .csproj 转换）我一直（而且我）期待 .netstandard 2.0，因为我认为这将是第一个“真正的”版本。

我知道 ASP.NET Core 1.1 仍受支持并将在未来 10 年运行，但你们非常勇敢地快速移动 __that__ 并削减 ASP.NET Core 的早期卖点之一。

如果您想从我们这边了解什么是阻止程序（除了目录服务）：我们仍在使用 EF6，并且仍在等待针对 netstandardwhatever 的官方 Open XML SDK NuGet 包。
迁移代码可能需要很长时间...

robertmuehsig 于 2017-05-09

❤1 👍1

是否有可能根据 Core 中发生的更改将其作为 Asp.Net Core 库版本维护阶段的一部分来推动netstandardXX的某种进程？

就目前而言，我有一个 WebForms/MVC 应用程序，我们即将触发将 ANC Web api 暴露给 SPA 并从 SPA（最终从 WebForms 遗留应用程序）调用，但我们无法在 CoreCLR 上进行开发，因为对Sybase（现为 SAP）Ase ADO.NET驱动程序的依赖（如果有人阅读本文可以按下 SAP 某处的按钮……遗憾的是，我似乎根本听不到关于这个或我已经知道的错误的消息9年了）。

阅读这个问题，我不太确定我的路径应该是什么。我唯一确信我可以计划的是桌面框架将继续存在一个有缺陷的驱动程序。我是否应该忽略过去几年对 ASP.NET 的更改，因为它们会浪费我的时间，而我应该只针对 WebApi2？我是否应该说继续使用 ANC 1.x，因为我知道我可能永远不会迁移并在应用程序中看到 2.x 的好处，我相信在未来 10 到 15 年内将在这里得到支持（WebForms 应用程序有自 1.1 框架发布以来已迁移和维护）？

bbarry 于 2017-05-09

@davidfowl

Span 本身有一个可以在任何地方运行的便携式版本，我不确定快速实施是否会
在 .NET 框架上。将添加到利用 Span 的 .NET Framework 的 API 可能需要比 Span 本身更长的时间，它非常广泛。我们最后一次在 .NET 中更改字符串和数组是什么时候
框架？

等等，什么？

并非我们所有人都是 Web 开发人员。多年来，我们一直在热切地等待更好的字符串处理支持，现在你突然告诉我们我们是 SOL？ .NET Framework 和基于它构建的无数非 Web 应用程序永远无法访问基于 Span 的字符串处理库？

这不再只是一个 ASP.NET 问题。它触及了 Microsoft 对 .NET Framework 及其基类库的长期承诺的核心。

Grauenwolf 于 2017-05-10

👍10

你知道，我真的必须把它交给像@davidfowl这样的人，让他们继续回应每一个人，感谢每一个人为这次讨论做出贡献。从今天早些时候开始，我有很多东西要赶上，但我觉得我从每个评论中学到了很多东西，每个人都在使用/希望使用 .NET 的目的。

我认为在大家的帮助下，我们最终会理顺一些路径，我希望各方都能得到考虑。

我很期待官方的消息

snickler 于 2017-05-10

如果我理解正确的话，net coreapp 2.0 将提供一个兼容性填充程序，它允许我们的 ASP.NET Core 2.0 项目依赖于我们遗留的 NetFx 类库（例如，net461）。
我在哪里可以找到有关此类兼容 shim 当前计划的功能/限制的更多信息？

dgaspar 于 2017-05-10

@dgaspar这不是很准确，它是这样工作的： netcoreapp2.0支持net461中的大多数API。如果您的库是为net461构建的，并且仅调用存在于netcoreapp2.0支持的子集中的 API，那么您无论如何都可以导入该库（将其视为覆盖，您更清楚）并让它运行，因为它调用的所有类和方法都应该在那里。

现在还有一个缺点：如果方法不存在或在某些方面不完全受支持，则会因缺少方法等而出现运行时错误等。因此，编译时检查并不是一个很好的保证。这有点像一把双刃剑，但对于一些永远不会更新的库来说，它们调用的 API 集就可以了。

NickCraver 于 2017-05-10

👍7

@NickCraver任何人都记得...

"imports": [ "dnxcore50", "portable-net45+win8" ]

我在 12 月发表的相关评论。 11 个竖起大拇指：

这里有些东西出轨了。我已经发布 C# 应用程序 15 年了。具有讽刺意味的是，随着 Microsoft 提供更高级别的抽象，我花费越来越多的时间深入挖掘我以前从未担心过的内部结构。你这样做是错的。
如果我想在运行时对编译器没有捕获的随机库和包管理引发的错误感到惊讶，我会用 Ruby 编写我的应用程序。

chadwackerman 于 2017-05-10

😄5 👍5

甚至 node.js 也允许我们轻松调用所有 netfx 库。

mvc 代码确实是最简单的部分。在 node.js 或 nancy 中重写可能需要几周时间，但移植业务和算法代码需要更长的时间，并证明它与旧代码一样可靠。更不用说我们没有来源的情况了。

以 RyuJit 为例，即使在发布到生产后，也发现了阻塞的主要错误，并且花了一年时间才完全解决。我们的软件也是如此，它们不是宠物店，而是帮助每天赚取数百万美元的工业工具。

UI框架变化很快，从winform到web。但核心业务逻辑/算法更加稳定和长寿。那么，要使用新的闪亮 UI 框架，我们需要重写/重新测试还是放弃我们的业务/算法代码？不，我们知道新的闪亮的将在 5 年内被更时尚的东西取代，但我们的业务/算法代码将继续使用。

qrli 于 2017-05-10

@qmfrederik

事后才想到，真正让我印象深刻的是，这个改变是现在做出的，比预览版早了几天。这似乎表明还没有技术上的理由这样做 - 那么为什么不在 ASP.NET Core v3 中进行更改呢？

我们接下来将支持 HTTP2，它需要新的 API。

davidfowl 于 2017-05-10

👍2

我也想支持工具方面。当前的还原/构建/测试等性能非常糟糕，而且非常痛苦。如果我们必须“停留在 1.0”上，我们是否仍然能够使用具有（希望）更好性能的新 SDK，还是会被 1.x SDK 卡住？

是的，这会奏效。

davidfowl 于 2017-05-10

@davidfowl

我们接下来会支持 HTTP2，它需要新的 API。<

那么将在 asp.net core 2.0 中提供的那种 HTTP2 支持在 1.x 中将不可用？这确实是我担心我们无法访问最新技术的问题，因为无论出于何种原因，我们都必须使用完整的 .net 框架。正如我在上面所说的那样，该过滤器是否需要六个月到一年的时间才能过滤到我正在使用的任何东西，但最终不想落后太远，这并不重要。由于现阶段代码共享和第三方库的使用，我需要完整的 .net 框架。

stefanolson 于 2017-05-10

👍1

最后，我澄清几点：

当我说遗留模块时，它们是依赖于 netfx 或 c++/cli dll 的 dll，这反过来可能会调用一些本机 dll。它们用于业务/算法，没有 COM，没有 asp.net。他们还不错。它们之所以成为遗留系统，主要是因为 .net 核心不运行它们。
从长远来看，迁移到网络核心是可能的，我们真的想要它。但这真的很难推动它发生。我们和第 3 方都需要几年的时间。
特定领域的库比技术堆栈更改的主流库慢得多。我们都知道python 3的例子。那些特定领域的库是真正的业务。

qrli 于 2017-05-10

👍1

@danielcrabtree

我认为 .NET Core 的意义在于重新构想 .NET Framework。 .NET Core 是跨平台、高性能、开源且快速发展的。<

这太棒了。挑战在于如何处理现有的代码库，以及如何让那些可用于 .net 核心的代码库。如果 WPF 在 .net core 上可用，那么我可以在任何地方使用 .net core。但由于它不是，我的代码在 WPF 和 ASP.net 之间共享，我需要一种方法来共享它们。但我不想在最新的网络技术和安全技术方面落后太远，其中大多数（全部？）听起来只会出现在 2.x 及更高版本中

stefanolson 于 2017-05-10

在这个线程和其他地方的文档中，有几次 .NET Core 被描述为跨平台。这被宣传为迁移到该平台的主要卖点之一。

情况似乎并非如此，但正如 Twitter 上的对话中所阐明的那样

https://twitter.com/James_M_South/status/861595907782987776

以及上面的评论；强调我的。

.NET Core 2 中剩余的较大差距是 System.DirectoryServices 和 System.Drawing。我们正在努力开发一个Windows 兼容包，它将在今年夏天在 Windows 上启用 .NET Core 上的这两个兼容包。

自从很早就试图用ImageSharp填补System.Drawing留下的空白时，我一直在努力使用 .NET Core，现在我既感到非常困惑，又有点不满，并问：

.NET Core 现在是什么？

这是来自MS Docs的描述。

.NET Core 是由 Microsoft 和 .NET 社区在 GitHub 上维护的通用开发平台。它是跨平台的，支持Windows、macOS和Linux，可用于设备、云和嵌入式/物联网场景。

又是那个跨平台声明。是还是不是？我认为试图确定这一点会导致整个开发社区的混乱。

我读到的每一个描述似乎都不一样。

我们可以吗：

请在某处写下一个体面的、一致的信息，以便我们实际上可以有一个目标和更好的整体理解。
了解System.DirectoryServices和System.Drawing的实际路线图

特别是System.Drawing既令人困惑又令人担忧。我无法理解为什么你会想要在任何平台上将该 API 移植到 .NET Core。它很难使用，在服务器上不受支持，并且缺少现代开发所需的许多关键功能（多线程、像素格式、ICC、EXIF、量化、索引 Png 等）。

JimBobSquarePants 于 2017-05-10

👍21 ❤1

这里有很多可识别的名字和面孔，我知道我只是在这里添加了一些噪音，但是：

目录服务
绘图（不是我需要它）
英孚

在做出如此大的突破之前，这些似乎是最关键的三件事。就个人而言，我所做的大部分工作都是在 net4x 上完成的，这完全是因为 EF6，因为 EFCore ......好吧...... :trollface:

tuespetre 于 2017-05-10

👍1

@stefanolson
我认为您应该将共享代码分离到 .NET 标准库中。然后它将可以从 .NET Framework 上的 WPF 和 ASP.NET 以及 .NET Core 和其他 .NET Core 应用程序上的 ASP.NET 使用。

@JimBobSquarePants
我不认为 Windows 兼容包是 .NET Core 的一部分。它是一个位于 .NET Core 之上的特定于 Windows 的库。您可以想象有一个特定于 Linux 的库公开了仅限 Linux 的功能。

我认为 Windows 兼容包旨在简化现有 .NET Framework 代码库的迁移。显然，一旦有人切换到 .NET Core，他们就应该考虑迁移到像 ImageSharp 这样更好的解决方案。

@stefanolson
他们甚至可以创建一个仅限 Windows 的 WPF 包，让您可以在 .NET Core 中创建 WPF 应用程序，但只能在 Windows 上运行。

danielcrabtree 于 2017-05-10

👍3

这个 GitHub 问题已在德国 IT 新闻网站上提及：
https://www.golem.de/news/asp-net-core-2-0-microsoft-veraergert-net-entwickler-mit-support-entscheidung-1705-127712.html

MJomaa 于 2017-05-10

😄2 👎1

谢谢@danielcrabtree ，这是我第一次听说任何兼容包。

JimBobSquarePants 于 2017-05-10

@MJomaa链接的翻译： https ://translate.google.com/translate?u=https%3A%2F%2Fwww.golem.de%2Fnews%2Fasp-net-core-2-0-microsoft-veraergert-

jnm2 于 2017-05-10

我正在等待 System.Xaml 被移植过来。

alexwiese 于 2017-05-10

😄1 👍1

@alexwiese不要屏住呼吸。

yaakov-h 于 2017-05-10

👎3

我正在等待 System.Xaml 被移植过来。

继续; 我会咬。您如何在您的网站上使用 Xaml？

benaadams 于 2017-05-10

继续; 我会咬。您如何在您的网站上使用 Xmal？

跨平台 UI（在“绿屏”控制台应用程序、Xamarin 应用程序和 Angular SPA 之间共享的屏幕模板），也用于业务规则引擎。

alexwiese 于 2017-05-10

哇，好的，所以您正在以某种方式将 XAML 的 XML 转换为 HTML 和 Javascript？够公平😄

不确定你是否只是在拖钓。

benaadams 于 2017-05-10

我也在做同样的事情，但实际上我看不到他们将 XAML 移植过来，考虑到此时它无法在不被执行的情况下被解析。

yaakov-h 于 2017-05-10

哇，好的，所以您正在以某种方式将 XAML 的 XML 转换为 HTML 和 Javascript？够公平😄

当然不是; 我先转换为 JSON 😉

alexwiese 于 2017-05-10

😄11

关于这个话题的另一篇新闻文章被引用了我们中的许多人： https ://www.infoq.com/news/2017/05/ASPNET-Core-2

cwe1ss 于 2017-05-10

@cwe1ss作者是@Grauenwolf

MJomaa 于 2017-05-10

@alexwiese @yaakov-h 我很想读一篇关于它的博文；听起来很有趣，而且一定会遇到与我过去不同的挑战。

benaadams 于 2017-05-10

这真的很糟糕。当您可以在需要时利用遗留库时，ASP.NET Core 是一个合理的卖点。如果可以使用新的东西来完成，请调整一些东西并以 .NET Core 为目标。否则，只需针对整个框架。

有了这种变化，这是一个全有或全无的跳跃。鉴于您并不总是事先了解所有依赖项，它会放大风险。

我理解快速行动的愿望，并在事情注定要发展的地方发展，但你会把你的用户抛在后面。人们倾向于迁移，而不是跳跃。大量的人不会离开当前。然后当他们这样做时，他们很可能会完全转移到另一个平台。说真的，你低估了这种风险。

这是最终应该采取的举措，但更像是在 2019 年末，或者最早在 2020 年。即使那样，您仍然需要一个长期模型来支持那些选择混合事物的人。

不，ASP.NET Core 1.x 不是答案。作为一个过渡阶段，它的不成熟性很好，可以轻松地向前迁移，但它不适合长期生活。开发这样一个平台的人和使用它的人的心态有很大的不同。请重新考虑这个方向。

chriswelles 于 2017-05-10

👍10

@davidfowl netcore的 edge.js 怎么样？它使 API 使用者负责平台检查，并且 netfx 和 netcore 之间的强类型接口足以满足大多数情况。

mtman 于 2017-05-10

那么这个模板会被删除吗？

目前它已融入 VS2017。

DamienDennehy 于 2017-05-10

😄2

多么令人无法接受的胡说八道，这再次证明它是一种尚未准备好迎接黄金时段和广泛采用的玩具技术。

我真的很感谢你们有一个愉快的骑行和编码经验，你可以在你的博客条目和推特上大放异彩（万岁！），改善你的 LinkedIn 个人资料和简历（万岁^2），所有的发布派对，女孩，饮料和东西看起来很有希望，但是..谁会使用它？您是否以企业为目标并希望获得大量采用和稳固的用户群？还是只有一些初创嬉皮士？！？

xprzemekw 于 2017-05-10

👎8 👍7 😕3 😄3

关于“完整跨度”的评论可能永远不会进入 .NET Framework，这让我非常担心。如果完整的 Span 不在 .NET Framework 中，那么我假设使用它的 API 永远无法成为未来的网络标准，这使得编写使用或公开高性能解析的跨平台库变得不可能？这意味着我们永久有效地坚持使用不安全的自定义实现......

你提到如果你希望你的库是跨平台的，那么你应该以 netstandard 为目标，但是如果不是一个广泛使用的库，那么 ASP.NET Core 是什么？你会推荐其他库开始放弃对 netstandard 的支持并切换到 .NET Core 吗？ JSON.NET 的下一个主要版本或其他什么都应该放弃 netstandard？它当然可以与快速解析有关！

注意 Java 设法以与 Netty 向后兼容的方式添加具有零复制等的快速 IO (https://netty.io/)

最后，我想对愿意闲逛并回答这些问题的人说声谢谢。我们非常感谢您的答案...

bencyoung 于 2017-05-10

👍6

@shanselman快速行动是一个崇高的目标，特别是对于那些在兼容性方面投入大量精力并以兼容方式设计事物的团队，例如 ASP.Net 团队。我知道他们多么想简化他们的问题域，我支持这一点，但是......

快速移动并同时“远离”您的客户也不是一件好事。您知道，您的客户（包括我）拥有大量的遗留软件和对现有应用程序和库的时间投资。你不能把我们抛在后面，去一个我们不会/不能跟随的地方。

您应该考虑您的客户，他们不能使用 .Net 核心，并且从现在起至少还要再使用一段时间才能使用完整框架。如果你离开完整的框架，你会让很多人滞留在旧版本上，并在 .Net 世界中造成巨大的分裂。

popcatalin81 于 2017-05-10

@JimBobSquarePants我在System.Drawing部分支持你。其他 repos 中有一些关于收回System.Drawing的讨论。根据该线程中的一些评论，我知道首先在 Windows 上会有一个“兼容包”，然后在所有 OS-es 上System.Drawing 。

我想知道它会是什么样子，以及它是否基于 Mono 的 libgdiplus（这将消除您对 System.Drawing 的一些担忧，但这是另一回事）

qmfrederik 于 2017-05-10

好吧，在我看来，有几个问题很重要：

这沟通得相当差。
人们没有参与这个决定。请注意，微软当然可以自由选择他们喜欢的方向，但不与社区讨论这种大的变化是不符合开源开发精神的。
社区没有可以用来检查这些类型决策的“宏伟计划”。起初，.NET Core 是完整框架的精简跨平台版本。然后，使用 .NET Standard 2.0，在许多人看来，.NET Core 2 就像是整个框架的直接替代品，当然在合理的范围内（没有 UWP、WinForms 等）。
.NET Core 2 将错过完整框架中的几个重要功能，例如 System.DirectoryServices。据我所知，这已得到承认，但也许可以更明确地将这些功能添加到 .NET Core 中。
由于完整框架缺少新功能，ASP.NET Core 2 将无法在完整框架上运行。我实际上对此完全没问题。如果将缺少的功能添加到完整框架中过于困难，那么不要这样做。让 ASP.NET Core 2 仅在 .NET Core 2 上运行实际上很有意义，尽管将它们作为一个产品提及可能不是描述它们关系的最佳方式。

我认为人们真正希望看到的是对 .NET 平台愿景的描述。事情会朝哪个方向发展？完整的框架会收到错误修正等但没有新功能吗？正在做些什么来向 .NET Core 添加缺失的功能，我们什么时候可以期待它们？对此进行解释有望大大缓解人们现在感到的焦虑。

ErikSchierboom 于 2017-05-10

👍5

@davidfowl我想这不仅仅是关于 HTTP 2.0；如果它真的是关于 HTTP 2.0，除了 HTTP 2.0 支持之外，你不能让 ASP.NET Core 2.0 目标 NetFX 吗？甚至可能是一个可插拔模型，以便社区可以在 NetFX 上实现 HTTP 2.0，如果他们真的想要的话？

qmfrederik 于 2017-05-10

👍2

@cokkiy @popcatalin81 @xprzemekw如果您没有什么建设性的话，请不要发表评论，这些评论对任何人都没有帮助。

采取@davidfowl https://github.com/aspnet/Home/issues/2022#issuecomment -300141134 所描述的举动是有正当理由的

推迟它的原因包括（比如 asp.net core 3.0）：

由于缺少许多功能，EF Core 尚未准备好替换 EF 6.0
没有准备好生产System.Drawing替换
没有System.DirectoryServices
提到了office xml sdk ，但这似乎已经在 netstandard 上可用，截至 2017-05-01 https://www.nuget.org/packages/DocumentFormat.OpenXml/
MS 范围之外的其他包在 .net 核心上不可用（nhibernate、各种数据库提供程序、ikvm）

为什么不这样做的原因包括：

人们将应用程序移植到具有遗留依赖项的 asp.net 核心，而不打算迁移到 .net 核心。
担心将 netstandard 抛在后面而不关心它。
一些 3rd 方包不太可能被移植到 .net 核心（可以说它们已经过时，但这可能只是我的看法）

建设性评论的示例是添加您希望查看这三种情况之一的原因或建议替代解决方案。如果您只想表达同意/不同意，请使用“反应”按钮。

Kukkimonsuta 于 2017-05-10

👍16

@Kukkimonsuta

人们将应用程序移植到具有遗留依赖项的 asp.net 核心，而不打算迁移到 .net 核心。

完全同意。因为微软已经宣布 ASP.NET Core 将同时适用于 .net core 和 .net 框架。现在将它们留在 AspNet Core 1.x 中是不公平的。

hikalkan 于 2017-05-10

👍16

最后总结的还不错。我只想补充一两件事：

1.) 应该可以使用 .NET Core 编写 Windows 服务（我知道 *NIX 平台上的守护进程工作方式不同）。所以仍然需要 ServiceBase，这与 EF 一起是高优先级的。

2.) 应该还可以使用 .NET Core 编写独立服务，并在现有的基于全框架的 .NET 应用程序中托管它们（即来自 Windows 窗体/WPF 应用程序的免费服务）以扩展它们。

后者对于缓慢的迁移场景确实是必需的，在这种情况下，不可能进行硬切并开始绿地。

gingters 于 2017-05-10

完全同意。因为微软已经宣布 ASP.NET Core 将同时适用于 .net core 和 .net 框架。现在将它们留在 AspNet Core 1.x 中是不公平的。

我还想再次强调，回到 .csproj 和 msbuild 的巨大变化主要是因为无法从现有（完整框架）.NET 项目中引用（ASP）.NET Core 项目。

这种变化使后者成为不可能（至少对于最大的 ASP.NET 部分而言）。那么为什么当时兼容性是最重要的（并造成了很多痛苦），但现在不是（并且再次造成了很多痛苦）？

gingters 于 2017-05-10

👍8

对不起，我也必须强调。但是有将近 500 条评论，我相信如果我作为一个微软人参与这个问题，我有两个选择：
1：静音问题
2：重新考虑我的决定

nokinger 于 2017-05-10

@gingters csproj 更改主要针对 _.net_ 核心，以便 xamarin、asp.net、uwp 和所有其他共享代码并引用其他项目类型，如本机代码。

此外，它使 asp.net core 2 项目能够再次通过 compat shim 引用完整的框架项目

aL3891 于 2017-05-10

@qmfrederik

甚至可能是一个可插拔模型，以便社区可以在 NetFX 上实现 HTTP 2.0，如果他们真的想要的话？

他们在技术上可以。但似乎他们不想这样做。对我来说，他们只是不想考虑企业/大型企业的真正需求，或者考虑向后兼容性或需要应对除未开发的东西之外的其他东西。

坦率地说，过去的期望管理完全针对希望慢慢扩展/迁移他们的东西到跨平台，同时也能够慢慢扩展/迁移他们现有应用程序的企业。所以这一举动与之前的预期管理完全不符。

gingters 于 2017-05-10

👍2

@aL3891

为了让 xamarin、asp.net、uwp 和所有其他共享代码

是的。确切地。这还包括使用 .NET Core 库的 WPF/Windows Forms 应用程序，当您想要继续使用 .NET Core 2 时，这现在是不可能的。

gingters 于 2017-05-10

有人可以准确解释为什么这些库不能针对netstandard2.0吗？

到目前为止，我一直认为netcoreapp是跨平台可执行文件的绰号（仅在 csproj 可执行项目中使用），但我从未将其视为平台，现在，它应该被视为真正的平台？为什么为什么为什么，以及我们是如何得出这个荒谬的选择的？

xoofx 于 2017-05-10

我看到了瞄准netcoreapp2.0背后的推理和理由，但我也认为这一举措还为时过早。生态系统还远未准备好，相当多的非常广泛使用的依赖项（包括可能希望用于新建开发的依赖项）并未针对任何网络标准，而且尚不清楚它们是否会。更不用说不针对 netstandard 的 Microsoft 包和 SDK，包括 Azure 的东西。

只是抛出一些东西：在 Windows 上运行时使用完整框架填充 .NET Core 2.0 是否可行？已经有 P/Invoke，所以可能会有某种 NETFX/Invoke，很好地包裹在外观包后面以填充 API 表面。

最后，我不认为我们中的任何人_想要_使用针对net461而不是netstandard2.0的东西，只是依赖要么不能（缺少 API）要么赢了'不（被遗弃，不想等）改变。为了解决这个问题，你需要给包开发者时间和一个非常清楚的沟通计划，什么时候发生什么变化，甚至可能是一些关于如何瞄准网络标准的指导。

wagich 于 2017-05-10

@xoofx

有人可以准确解释为什么这些库不能针对 netstandard2.0 吗？

据我了解（如果我错了，请有人纠正我），因为完整的框架（至少4.6.1 ）应该符合netstandard 2.0 ，并且有他们需要的功能在可预见的未来不会出现在完整的框架中

javiercampos 于 2017-05-10

我觉得有趣的一件事与关于“愿景是什么？”的整个问题有关。是经常提到的System.Drawing 。

我觉得这很有趣，因为类（与 System.Drawing.Color 之类的结构不同）System.Drawing 多年来一直不支持 ASP.net，至少从 .net Framework 3.5 时代开始。从文档中：

不支持在 Windows 或 ASP.NET 服务中使用 System.Drawing 命名空间中的类。尝试从这些应用程序类型之一中使用这些类可能会产生意想不到的问题，例如服务性能下降和运行时异常。有关受支持的替代方法，请参阅 Windows 映像组件。

当然，现在人们实际上一直在使用 GDI+，因为在很多情况下，它都有效。我不是在这里讨论依赖不受支持的行为是否是个好主意。

但我确实想知道 .net Core 和 ASP.net Core 现在的愿景是什么：它是对好想法的重新实现和消除多年的垃圾（又名“.net - The Good Parts”）吗？在那种情况下，为什么要引入 System.Drawing 呢？

或者它基本上是对整个 .net 框架的重写，使其成为多平台，基本上是一个更好的 Mono？

我不争论，我只是想知道。我觉得.net和.net Core团队需要做一些反省，因为我觉得开始是前者，现在是后者。

我不介意留在 Windows 上的 .net Framework（我在这里谈论的是我自己的项目，因为我不是为我的雇主推动架构）。 .net Framework 运行良好，并且在 Windows Server 2016 上至少支持到 2027 年。

使用 .net 框架当然会带来妥协。例如，HTTP/2 支持比其他 Web 堆栈晚得多，并且需要完整的操作系统升级 - 如果我错了请纠正我，但据我所知，没有办法在 Windows 上使用 ASP.net 进行 HTTP/2服务器 2012 R2。但这些妥协是值得的，因为可以有力地保证再维持 10 年的现状。

但是为了考虑新开发的完整框架，我很想在完整框架上看到 ASP.net 的路线图 - ASP.net MVC 6、Web API 3、SignalR 3 等的计划。我只是不想要它基本上是这一代的 Visual Basic 6/Classic ASP(.net)。

我觉得专注于 .net Core 确实符合 ASP.net Core 的最大利益，因为快节奏带来了很多好东西，而且我觉得这是永远的第一次，.net Core准备好生产，进行新的开发。快速行动，创新，基本上做 Node.js 如此成功的事情（记住他们有自己的稳定性/创新戏剧，请参阅 io.js）。

我要感谢团队中在这里发表评论的每个人 - 这是一个包含许多不同观点的长线程，但却是一次民间讨论。我知道@davidfowl一直在问“那么，为了移植，你到底错过了什么？”一定是令人沮丧的。并且只在这个线程中获得有用的答案。

但是对于当前使用 .net Framework 的人来说，_感觉_当前的 ASP.net 基本上已经“完成”了，所有新的开发都将发生在 ASP.net Core 中，它只能在他们自己的平台上运行，这也是一种真正的恐惧和沮丧。可能永远无法迁移到 - 基本上是 Visual Basic 6 的人在被告知“迁移到 VB.net，或者发现自己在几年后陷入困境”时发生的事情。

我觉得一旦那些永远无法使用它的人确信它的好部分仍然会找到他们的方式，那么真正加倍努力使 .net Core 上的 ASP.net Core 2.0 成为一个令人惊叹的 Web 堆栈要容易得多进入他们的经典 ASP.net 堆栈。

不管怎样，我的胡说八道就够了。这是一个团队很难解决的问题，我不羡慕你。我（以及这里的许多其他人）想要的只是对整个生态系统的发展方向有所了解。

mstum 于 2017-05-10

👍2 ❤1

据我了解（如果我错了，请有人纠正我），因为完整的框架应该符合 netstandard 2.0，并且在可预见的将来，他们需要的一些功能不会出现在完整框架中

谢谢！我想知道具体有哪些功能？ @davidfowl上面提到的 HTTP2 是 - 原因之一？一个可以实现到任何分离的System.Http2程序集的协议如何导致分叉整个 .NET 平台？有人可以提供有关完整推理的更多详细信息吗？

xoofx 于 2017-05-10

@gingters但并非不可能，库仍然可以针对 .netstandard 并由 46 和核心使用，它只是 asp.net 核心_itself_，情况并非如此。

aL3891 于 2017-05-10

@xoofx https://github.com/aspnet/Home/issues/2022#issuecomment -300141134

davidfowl 于 2017-05-10

转发，因为它被掩埋且不可链接：

所以如果理解正确，我们最终会用netstandard代替net framework。

不是那不正确。我不确定你是如何得出这个结论的。 .NET Standard 将始终是支持它的每个运行时的子集。

我想在这里抛出一些疯狂的东西，因为它已经被提到过几次了。我要说的与会发生什么无关，现在都是猜测。有几个人问我们为什么要针对 .NET Core 而不是 .NET Standard。

我们已经将字符串确定为我们希望在 .NET Core 中尝试解决的主要问题之一，有很多想法，但其中之一是默认将字符串设置为 utf8（大量兼容问题，但请在此处关注我）。
我们想要修复的另一件事是能够获取廉价的数组/字符串切片，任何连续内存。我们已经添加了Span<T>并正在查看Buffer<T>来表示这一点。这可能意味着 String 和 Array 实现了新的接口，使获取需要 0 分配的切片成为可能。
这导致 String 上的新方法允许拆分而不是每次都分配数组。
这会导致使用Span<char>和Span<byte>的 Int、UInt 等 (TryParse) 重载。
这导致采用Span<byte>的新编码例程。
Buffer<T>和Span<T>让您以统一的方式表示内存，我们希望升级网络堆栈以允许传递采用Span<T>或Buffer<T>的预固定缓冲区
Kestrel 将在 2.x 时间范围内实现 HTTP2（目前针对 2.1），这需要 SSL 流上的新 API 来执行 ALPN（https://en.wikipedia.org/wiki/Application-Layer_Protocol_Negotiation）。
.NET Core 上的 Http 客户端支持双工流式传输，它可以通过单个非 websocket http 请求在信号器中通过 http 实现流式传输端点。
我们从 HttpClient 和 System.Net.Http 分叉了标头解析器实现并将它们重命名（https://github.com/aspnet/HttpAbstractions/tree/d1d9bceff56cb44a194ae36923ce687e5e353006/src/Microsoft.Net.Http.Headers），以便我们可以改进它们并让它们同时支持 .NET Framework 和 .NET Core。 .NET Core 有一份这些改进的副本，因为没有必要改进它们（我们无法使用它们），所以没有恢复。
有一堆新的线程原语需要新的 API，如果我们能够使用它们，它们将点亮新的场景（https://github.com/dotnet/corefx/issues?q=is%3Aopen+is%3Aissue+ author%3Adavidfowl+label%3Aarea-System.Threading），这些只是我个人提交的一些内容。

如果没有修改核心原语的能力，我们鼓励将它们分叉并制作看起来像它们但不是它们的东西。这就是我们在 ASP.NET Core https://github.com/aspnet/Common/tree/dev/src/Microsoft.Extensions.Primitives 中拥有自己的小 BCL 的原因。

那只是我可以看到我们在短期内所做的事情的随机转储，这些事情会影响 .NET 的非常基本的部分。

davidfowl 于 2017-05-10

👍9 ❤6

大家好，感谢您进行非常有趣的讨论。该线程已达到临界质量，并且正在询问和重新回答一些相同的问题。我现在要鞠躬了👋。

davidfowl 于 2017-05-10

👍21 ❤9 👎7

@aL3891

它只是 asp.net 核心本身，情况并非如此

其中 - 仅举个例子 - 杀死了将 ASP.NET Core 2 作为 Windows 服务托管（因为 .NET Core 中缺少所有 api，而 TopShelf 只是在完整框架上运行）。这实际上是一个非常严格的限制。并且还不允许在现有 WPF / Windows Forms 应用程序中托管 .NET Core 2 服务扩展，这是与旧版应用程序集成用例的常见场景。

gingters 于 2017-05-10

Span<T>的快速版本在.NET full 上不可用真的很奇怪：那么微软将如何加速 Roslyn？他们有快速的Span<T>和附带的技术，但不会在地球上的每个 Visual Studio 安装中使用它，因为......政治？因为在 MS 的树上没有经理敢说：我们必须在 .NET 上投入更多的精力？

但是，不要让我破坏今天晚些时候从 //build 传播的彩虹和颜色营销 blabla 会谈。我相信 MS 会描绘出一幅美好的画面，一切都很好，而地球上的其他人仍然生活在山洞里。

FransBouma 于 2017-05-10

👍18 👎1

@davidfowl感谢您在这里的努力，您的见解和答案肯定帮助了很多人。 👏

louislewis2 于 2017-05-10

@gingters它绝对限制了一组场景，但我只是说整个 netstandard/csproj 的努力并没有因此而浪费

aL3891 于 2017-05-10

@davidfowl我刚刚偶然发现了这个消息，这有点吓人。直到现在，我确信如果我支持与 .NETStandard 2.0 的兼容性，我最终可以在我的应用程序中切换到使用 ASP.NET Core 2.0，同时仍然在完整的框架上运行。除非我完全没有抓住重点，否则这将不再可能。

我刚刚运行了最新版本的 API 分析器，我依赖的 .NET Standard 2.0 中有许多缺失的 API。其中一些我可以摆脱（例如 System.Configuration），即使它很痛苦。

其他的，我还不知道。例如，我使用运行时代码生成并依赖 System.Reflection.Emit.ILGenerator、TypeBuilder 等。我不能只摆脱这些，它是产品的核心部分。

我对 API Analyzer 进行了进一步研究，其中一些似乎已被 .NET Core 2.0 + Extensions 覆盖，但仍然缺少以下 API：
M:System.AppDomain.DefineDynamicAssembly(System.Reflection.AssemblyName,System.Reflection.Emit.AssemblyBuilderAccess,System.Collections.Generic.IEnumerable{System.Reflection.Emit.CustomAttributeBuilder})
M:System.AppDomain.DefineDynamicAssembly(System.Reflection.AssemblyName,System.Reflection.Emit.AssemblyBuilderAccess,System.String)
M:System.AppDomain.DefineDynamicAssembly(System.Reflection.AssemblyName,System.Reflection.Emit.AssemblyBuilderAccess,System.String,System.Boolean,System.Collections.Generic.IEnumerable{System.Reflection.Emit.CustomAttributeBuilder})
M:System.Reflection.Emit.AssemblyBuilder.DefineDynamicModule(System.String,System.Boolean)
M:System.Reflection.Emit.AssemblyBuilder.DefineDynamicModule(System.String,System.String,System.Boolean)
M:System.Reflection.Emit.AssemblyBuilder.DefineVersionInfoResource
M:System.Reflection.Emit.AssemblyBuilder.Save(System.String)
M:System.Reflection.Emit.AssemblyBuilder.Save(System.String,System.Reflection.PortableExecutableKinds,System.Reflection.ImageFileMachine)
M：System.Reflection.Emit.ILGenerator.MarkSequencePoint（System.Diagnostics.SymbolStore.ISymbolDocumentWriter，System.Int32，System.Int32，System.Int32，System.Int32）
M:System.Reflection.Emit.LocalBuilder.SetLocalSymInfo(System.String)
M:System.Reflection.Emit.ModuleBuilder.DefineDocument(System.String,System.Guid,System.Guid,System.Guid)
M:System.Reflection.Emit.TypeBuilder.CreateType

我在https://apisof.net/catalog中查看了一下，似乎那里的信息与 API 分析器输出不同，即那里列出了一些被分析器标记为不支持的 API (TypeBuilder.CreateType)。所以，我可能会没事，但我不知道，直到我尝试。其他的，它们肯定会丢失，例如 AssemblyBuilder.Save(...)

所以，底线是：我不仅能够将 ASP.NET Core 2.0 放入完整的框架堆栈，而且只保留我的旧依赖项。我也将无法使用 .NET Standard 2.0。相反，我必须将 Big Bang 的所有内容都移植到 ASP.NET Core 2.0，因为这是唯一一个几乎涵盖了我需要的所有内容的 API。在我迁移之前，我将无法在 ASP.NET Core 2.0 上开发新的 Web 应用程序层。所以，它实际上是一个大爆炸，然后是一个真正的大爆炸。

MichaelKetting 于 2017-05-10

@davidfowl感谢您提供详细信息。

我完全支持 .NET Core，实际上我不太关心 .NET Full Framework……但我关心netstandard2.0只是因为它带来了大部分 .NET full framework API，并且2.0版本作为“连接”版本，即帮助人们将他们的代码从 .NET Full 迁移到 .NET Core...永远的完整框架...但听起来netstandard2.0毕竟将成为新的 PCL...

这么公平，.NET 完整框架现在真的需要一个退休计划（ System.Drawing阻碍你？来吧， SkiaSharp是等待更好和跨平台）并让 .NET Core 2.0 进化自己的全速！

xoofx 于 2017-05-10

👍1

@davidfowl最初，API 明智的，Net Core 应该是在所有平台上运行的完整框架的子集，并且任何与 Core 有关的 API 更改都将在这两个平台上进行。至少那是最初的承诺……随着这个新的（不知从何而来）方向，事情现在看起来非常不同。

你提到的东西都很棒，我现在很想拥有它们，但是在非常需要它们的完整框架上，我目前正在开发一个 WPF 应用程序，其中 Span和相关的 API 将是天赐之物，我们目前有自定义 TryParse 例程，用于日期时间和时间跨度以及原始获取索引，这是支持的噩梦，因为它们需要具有文化意识。

您想发展框架是完全可以理解的，但不可理解的是，为什么要与现有客户产生这种分歧，让他们滞留在一个现在垂死的平台上？完整的框架？

popcatalin81 于 2017-05-10

@popcatalin81 （在事情变得太离题之前，但有成为一个男人的风险）-跨度是关于在没有分配的情况下移动内存，它与 DateTime 无关。

graemechristie 于 2017-05-10

@popcatalin81和netstandard2.0我很确定我们甚至可以期望WPF和System.Drawing在 .NET Core 上运行（仅限 Windows，它们显然不会在非Windows 平台......），afaik，这些库没有使用任何 CLR 特殊功能......它们只需要用netstandard2.0重新编译......（只有 .NET 部分，本机部分将是相同 - wpf 组合引擎，或直接调用 System.Drawing 的 Win32 函数...）

xoofx 于 2017-05-10

我没有像我应该的那样密切关注整个“核心”旅程，因此有几件事对我来说真的很突出。

似乎一开始 ASP.NET 团队领先于其他所有人（或者至少被指控这样做），然后又被重新控制，现在由于已经提到的原因不得不再次挣脱。这是一个公平的评价吗？

如果是这样，那么现在面临的许多困难似乎都是可以预见的，并且新的现代 ASP.NET / .NET 从一开始就应该是一个独立的东西。

我在整个线程中看到的主要问题是人们已经根据不再适用的承诺和假设进行了大量投资。

感觉很多事情都是可以避免的。

我离基地很远吗？

letdowncrush 于 2017-05-10

@davidfowl @DamianEdwards @shanselman

我有一些面向net462的生产中的 ASP.NET Core 1.x 应用程序，因为它们提供了功能并使用下面的命名空间。我看不到netstandard2.0 work in progress API reference 中的命名空间。

1.ADFS集成：

• System.IdentityModel.Protocols.WSTrust
• System.IdentityModel.Tokens
• System.ServiceModel
• System.ServiceModel.Security

2. Atom/RSS 提要生成：

• System.ServiceModel.Syndication

我想让这些现有的应用程序在未来以netcoreapp2.0目标。在每种情况下，我最好的行动方案是什么？例如，我是否错过了现有的 NuGet 包，还是应该等待未来的版本？

mattbrooks2010 于 2017-05-10

👍2

有很多东西迫使我进入全栈，具有讽刺意味的是，其中大部分是微软技术。 CRM Dynamics SDK、Azure SDK、XLST 命名空间支持、无头 ADAL 登录（仅在全栈中可用）等...

这种变化只会进一步隔离已经很小的开发者群体，勇敢/愚蠢到足以及早采用 .Net Core。

talynone 于 2017-05-10

👍15

@davidfowl

我们接下来将支持 HTTP2，它需要新的 API。

我只是部分理解这一点。对于 HTTP/2，主要的阻碍是 ALPN 对 TLS 的支持，所以我们现在不能拥有它。但是，根据 CoreFx 存储库中对相关请求的评论，对于 .NET Core 2.0，这也不会及时发生。只是稍后（2.2？3.0？）这意味着从 HTTP/2 的角度来看，如果 ASP.NET Core 依赖于 corefx 2.0 或 .netstandard 2.0 无关紧要 - 它无论如何都不会工作。只有稍后，当版本号再次增加时。

除此之外，HTTP/2 问题主要影响网络服务器（Kestrel）而不是整个框架。除了“维护多个东西很难看”的原因之外，我认为没有理由不能拥有一个没有对 .NET 标准的 HTTP/2 支持的网络服务器，以及一个为未来的 .NET Core 版本提供它的网络服务器。

Matthias247 于 2017-05-10

❤6 👍2

@davidfowl在整个讨论中还没有真正涉及到一件事。我完全了解技术背景，我完全同意你的推理。特别是，我同意继续使用 1.x（可能会延长支持时间），特别是如果目前缺少像 SignalR 这样的痛点将在未来添加 1.x 支持，这将是一个技术上可行的解决方案对于这里讨论的所有案例中的大多数。

然而，问题不是技术性质的，而是心理问题。正如这里的一些人所指出的，ASP.NET Core 的采用仍处于早期阶段。想一想您将要传达的信息：您将很快发布 2.x 版本，然后很可能立即开始对 3.x 版本进行战略规划，一切都是公开的（这通常是一件好事）。这样做的结果是，即使没有强制要求大多数人使用 2.x，即使您可以通过支持 1.x 提供合理的技术解决方案，但在人们的脑海中，积极迁移现有的想法当版本 3 已经有工作时，“版本 1”的解决方案将是一个即时且不可接受的心理障碍。真正的危险是，这将导致一个先有鸡还是先有蛋的问题，人们不会将现有项目迁移到 ASP.NET Core 并且库作者不会将他们的东西移植到 .NET Core，因为没有足够的需求和压力，这将有效地可能会在很长一段时间内进一步降低采用率。

正如一些人还提到的那样：显然很多人，即使他们在某个时候意识到这一举措的到来，也没有想到这次削减会这么快发生。此外，在过去几个月中，我们听到并阅读了很多关于 2.x（.NET Core、.NET Standard 等）如何稳定和统一事物的演讲、采访和帖子。因此，在很多人看来，“2.x”已经成为“成熟”的等价物，无论这种说法在技术上的根据可能有或没有。你为 2.x 建立兴奋的方式，现在在短时间内取消了 1.x 的核心功能，这是一个最不幸的举动，这很可能已经将争论从技术推理转移到情感推理，即使从表面上看，我们似乎仍然只是在这里讨论技术细节。你将很难改变这种看法并重新建立对 1.x 作为向 ASP.NET Core 的可靠迁移目标的广泛信任和信心。

我个人的建议是将 2.0 作为支持 .NET Framework 的最后一个主要版本发布，但与其花一年或更长时间来放弃该支持，不如更快地转向 3.x。将 3.x 用于所有这些在考虑向后兼容性的情况下不可能实现的技术特性，并在 2.0 推出后立即开始使用 3.x。这样您就可以同时获得多项好处：您可以保留原来的 1.x 支持计划。人们在 2.x 中获得了 .NET 支持，在他们的脑海中，它在过去几个月中已经成为“成熟”版本。他们可以满怀信心地迁移到“最新最好的”，现在他们非常清楚 3.x 将放弃该支持这一事实，并且有足够的时间来计划他们的迁移策略（如有必要）。而且您不需要放慢速度（或只放慢速度）添加新功能和快速发展 ASP.NET Core。

同样，该提议与您目前打算做的没有太大区别，只是应用了一些不同的版本控制忍术。最近应用了此更改的事实意味着，从技术上讲，这只会向后退一小步，直到您能够再次全速前进，但它会很好地避开这些心理问题。

/cc @DamianEdwards @shanselman

MisterGoodcat 于 2017-05-10

👍38 👎3

并在构建时宣布 Microsoft Shrink。（对不起，我无法抗拒）
虽然我同意@MisterGoodcat关于 WHY 的一切，但我想知道，我们真的需要微软来管理我们的情感缺陷/需求吗？

Bartmax 于 2017-05-10

.NET Framework 多年来一直很稳定但进展缓慢，作为几乎所有类型的 .NET 应用程序的维护者，我同意必须对此采取一些措施，甚至可能“让它摆脱困境”是既然微软已经选择了 .NET Core 而不是其他选项，那么这是一个及时的选项。但是这个问题说明了微软是多么盲目地认为过去付出的努力并不会自动移植过来。

对于一家以专注于开发人员和开发人员工具而闻名的公司来说，微软仅以自身依赖项的形式要求阻止程序是非常短视的。 DirectoryServices 和 Drawing 是最受欢迎的单一阻止程序，这并不让我感到惊讶，但这并不意味着没有所有内部组件、第三方组件和 COM 互操作的长尾之母，这些组件要么是不可能的、不切实际的，要么是极其昂贵的（尤其是升级形式）随身携带。

我理解微软从 BCL 或扩展的 .NET 框架（WCF 等）询问自己的东西以确保他们自己处理正确的东西的论点，但同样的问题不应该成为驱动决策移动整个平台。如果计划是在某个阶段一直放弃 .NET Framework，为什么不进行沟通呢？如果这个决定是最近做出的，为什么不在那个时候传达呢？为什么不与我们交谈并与我们协商？我知道不是我们每个人都会给出合格的分析，但是当我在这个线程中看到 MVP，你最热心的支持者和最活跃的用户对此视而不见时，我不太相信微软会关心它的客户。 .

而且我也理解我说“微软”很容易的论点。我知道它是由没有无限能力的个人组成的。但我并不要求钢铁般的巨石做出巨大的努力——我要求的是沟通、诚实和尊重。我要求当你们所有在这个产品上工作并想要做出影响客户的改变时，你们要与社区互动而不是掷骰子。我们为您撰写文章，我们选择您的平台，当您做正确的事情时（比如让人们了解整个性能提升，无偿社区成员 Ben Adams 做出了不可磨灭的贡献），我们会观看社区站立。但这是双向的。将我们用作扩音器，我们可能不会以这种方式做出反应。

JesperTreetop 于 2017-05-10

👍5 ❤1

@Bartmax要么就是这样，要么给每个人一个关于核心、asp.net 核心、asp.net 核心非核心、netstandardbanana、.net、system.web 差异的强制性 2 小时课程。 asp.net 5（我的意思是 6）。
并开始更清楚地传达路线图和意图。

对于那些永远无法放弃完整框架的人来说，这仍然不是一个解决方案。在未来的某个地方，我们最终会得到两个社区。

在一个完美的世界里，asp.net 核心在核心上会更快，甚至可能有一些 .net 不可用的专有功能。但是大多数东西都是网络标准的，至少在可预见的未来，其他一切都将是交叉编译的。人们可以学习核心，因为如果他们必须在遗留项目上工作，唯一的区别就是引导部分，而不是整个 asp.net 部分。

hallatore 于 2017-05-10

👍2 ❤1

没有看到任何人是一个普通的 asp.net 开发人员商店可以对这一前进充满信心。

leriksen71 于 2017-05-10

作为一个不得不使用很多 C++/CLI 库的人，这种潜在的变化给我留下了可怕的选择：

1) 永远使用当前稳定的 asp.net 核心版本，而没有机会利用新功能或安全修复。

2) 投入大量时间（最终是金钱）来更换所有那些 C++/CLI 库，没有客户愿意为此支付一分钱。

3）完全放弃asp.net核心

我可以理解这种改变在未来是必要的，我完全赞成。我无法理解和接受的是时间框架。这种规模的事情是您将提前一年宣布为路线图目标的事情，作为即将在 3.x 甚至 4.x 版本中发生的重大变化，而不是在下一个版本中放弃它......

leak 于 2017-05-10

👍5

@davidfowl netcore的 edge.js 怎么样？它使 API 使用者负责平台检查，并且 netfx 和 netcore 之间的强类型接口足以满足大多数情况。

对我来说，这看起来是一个理想的解决方案：

1) 无需猜测您的 netfx 代码是否会在 netcore 下运行——它使用 netfx 运行时，进程内
2）不阻碍核心
3) 如果新的核心 API 变得足够流行，以至于开发人员会放弃对可能最低版本的 netstandard 的支持，而这在 netfx 领域并非如此，那么您可以为相反的方向提供一座桥梁

mtman 于 2017-05-10

对于那些建议使用双平台 ASP.NET Core 的人，一个在旧的 .NET 上运行，没有任何闪亮的新字符串和跨度功能，一个在 .NET Core 2 上具有这些功能......好吧，我建议采取看看代码。

在最基本的层面上，任何 Web 框架：

获取表示 UTF8 编码字符串 (_BOBTRUES_) 的字节块，解释它们并将它们作为强类型对象传递到您的代码中
获取代码的结果并将它们转换回 _BOBTRUES_。

因此，如果您正在构建 Web 框架，那么您真正需要的是理解 _BOBTRUES_ 的低级原语，这是有道理的，不是吗？

如果您编写的大部分代码都依赖于_BOBTRUES_，但您还必须支持另一个不知道_BOBTRUES_ 是什么的运行时，那么您将编写所有代码两次，所有代码都充斥着编译器指令或复杂的构建文件. 而且您将不得不继续编写和编辑所有重复的代码，同时尝试使您的 Web 框架 _awesome_，只要它不仅需要完整的 .NET 来理解_BOBTRUES_，还有 Mono、UWP、Xamarin、Unity3D 以及任何其他实现您添加 _BOBTRUES_ 要求的 NETStandard 的东西，其中许多一开始并不真正关心 _BOBTRUES_。

当然，您必须将所有这些代码编写两次的唯一原因是因为有一堆第一方和第三方软件包

System.Drawing、System.DirectoryServices 等，或
等待 NETStandard 2.0，因为 1.x 缺少他们需要的 API，或者
由没有时间或动力迁移到 NETStandard 的人维护
被遗弃，或
依赖于上述之一的上游包

撇开 System.* 位不谈，对于许多其他软件包，也许知道 ASP.NET Core 用户可以在完整的 .NET 上运行，这是否会使推迟到 NETStandard 的端口更容易证明是合理的？ _“是的，我们支持 ASP.NET Core，但目前仅在完整的 .NET 上......”_ 对于需要在 Linux 容器中运行 .NET Core 应用程序或想要在 Mac 上开发它们的人来说，这同样令人沮丧，并且没有“暂时停留在版本 X”的解决方法。没有 NHibernate，没有 OData，没有 EF6，什么都没有。

因此，如果这是微软内部和外部的团队需要将他们的包正确迁移到 NETStandard 2.0 以便他们可以被_所有_ ASP.NET 开发人员*使用的裤子，而不仅仅是那些在 Windows 服务器上运行的完整.NET，那么这是一件_好事_。

*请记住，在 .NET Core 2.0 上运行的 ASP.NET Core 2.0 不需要 _publish_ NETStandard 包就可以 _consume_ 它们。

markrendle 于 2017-05-10

👍5

指示@JamesNK只编写解析器的评论真的很优雅，特别是考虑到您为他放弃了自己的解析器。这是他在自己的时间写的，以推动您的平台向前发展。

是的，整个堆栈的移动速度较慢，但这也意味着您有时间了解框架。在正常框架中还有很多工作要做，所以老实说，我真的不明白为什么我们需要像.Net core 这样的东西。如果跨平台是一个问题，你刚买了 Xamarin，他们几乎可以在任何东西上运行 .Net。包括一块该死的手表。

也许是路线图？

boeremak 于 2017-05-10

❤5

我们看不懂祖辈的源代码，看不懂他们的算法，一夜之间懵了！ .
如果 Asp.net Core 来了会发生什么，兄弟，Kılıçdaroğlu 没有领导素质。

heustr 于 2017-05-10

😕5 😄2 👎2

因此，如果这是 Microsoft 内部和外部团队需要将他们的包正确迁移到 NETStandard 2.0 以便所有 ASP.NET 开发人员*，而不仅仅是那些在 Windows 服务器上运行.NET，那么这是一件好事。

@markrendle如果库作者遵循 ASP.NET Core 逻辑，他们不会直接跳到 netcoreapp 而不是 netstandard 吗？毕竟他们也可以从新的 API 中受益？为什么要打扰netstandard？毕竟 ASP.NET 只是另一个库（尽管它很大）

bencyoung 于 2017-05-10

👍8

我的情况与该线程中许多其他人提到的完全相同：我的公司有一个大型 SaaS 应用程序，它依赖于大量内部和第三方库，这些库可能永远无法用于 .NET Core。前进的计划始终是在完整的 .NET 框架上迁移到 ASP.NET Core，然后在 5 年多的时间里慢慢找到这些第三方组件的替代品。这个（非）公告使这些计划完全混乱。

SebastianToet 于 2017-05-10

👍16

我的印象是 ASP.NET Core 没有在 .NET 桌面框架上运行。编辑. 文档页面指出 ASP.NET Core 在完整的 .NET Framework 上运行，因此它清楚地暗示了支持。

似乎还有另一种选择，以防没有人提出这个建议。

毕竟，ASP.NET Core 是开源的。这意味着可能有两个不同版本的 ASP.NET Core：

ASP.NET Core：针对 .NET Core (netcoreapp2.0)，现有构建
“ASP.NET Core Standard” ：另一个构建，它以 .NET Standard（netstandard1.* 和 net4*）为目标，并根据需要在 .NET Desktop Framework 和其他标准平台上运行。

Core 构建将链接到 .NET Core，而Core Standard构建将受限于 netstandard1.* 和 net4* 以及更高版本的 .NET standard 2.0+ 上可用的内容；移动更慢，但更兼容。 .NET Core 更适合新建和初创企业，标准版更适合棕地、迁移和企业。

微软团队采取的路径作为主线选项是有意义的，Core 是框架的未来。同时，为 netstandard 维护一个额外的目标应该可以用最少的努力来实现。它可以是一个开源项目。也许这实际上也可以由微软本着兼容的精神来完成。

这意味着“ASP.NET Core Standard”可能不会获得所有新功能，但由于这个分支是为了兼容，使用它的用户将有信心可以使用标准框架中所有支持的功能，并且标准分支将在 Github 上无限期可用，并且志愿者可以将修复和更新从核心分支移植到标准分支。

如果有可能在 ASP.NET 核心中保持 .NET 桌面框架的兼容性这么长时间，那么维护另一个版本应该不会是一个很大的障碍。许多其他 .NET 项目对多目标执行相同的操作，例如 protobuf-net，并带有一些条件编译语句。

基本上，需要 Active Directory 和 System.Drawing 的用户可以使用 ASP.NET Core Standard，但仅限于使用 Windows。但是，一旦库可用，他们的代码就可以轻松地移植到 .NET Core，并按照自己的节奏进行，不会有未来缺乏支持的风险。

我想问题是团队是否能够提供这样的分支。对于像 ASP.NET 这样的基础库，这可能是必要的。我认为需要提供从 .NET Framework 到 .NET Core 的路径，无论如何在某些时候需要这些类型的权宜之计解决方案。软件是灵活的，这种解决方案将允许必要的过渡顺利进行。

我认为，与它将为整个社区提供的显着更大的采用和更好的迁移相比，这样做的额外努力应该被视为一项小投资。拥有数以千计的用户肯定会帮助为项目产生更多贡献，以抵消维护两个目标的工作。

vectorix 于 2017-05-10

👎3

@bencyoung

如果库作者遵循 ASP.NET Core 逻辑，他们不会直接跳到 netcoreapp 而不是 netstandard 吗？毕竟他们也可以从新的 API 中受益？为什么要打扰netstandard？毕竟 ASP.NET 只是另一个库（尽管它很大）

好吧，如果库作者正在编写一些从新原语和对 _BOBTRUES_ 的框架级支持中受益匪浅的东西，那么我想这可能是有道理的（我完全可以看到 JSON 或其他支持这些的序列化程序库的好案例，顺便提一句）。但是，如果包中的代码并不真正关心 _BOBTRUES_ 或任何其他东西，那么当netstandard20 _也可以工作时，您必须特别血腥地编写netcoreapp20 _ .

markrendle 于 2017-05-10

@markrendle所以你会很高兴说Newtonsoft.JSON为其下一个版本这样做，放弃对任何现有版本的支持一年的时间表？您对解析、IO 和高性能库开始放弃对 netstandard 和 .NET Framework 的支持感到高兴吗？

bencyoung 于 2017-05-10

👍9

关于如何解决此问题的建议：

使 asp.net core 2.x 在 .net 上运行，并将仅核心的东西移至版本 3.x（将 2.0 的面向用户的功能反向移植到 1.x 上并将其称为 2.0）
从一开始就明确指出，asp.net core 2.x 将是在 .net 上运行的最后一个版本，但要让它有很长的生命周期。
专注于制作用于验证 lib 是否可以更好地在 netstandard2.x 上运行的工具。目前的猜测工作是什么让人们感到害怕。
专注于帮助那些许多使用的库获得 netstandard2.x/core 支持。（即使它只是 Windows）
调整微软与社区之间的沟通。是的，我们想要速度/功能/等，但许多还需要可靠性/传统。我们需要找到比这更好的中间立场。

hallatore 于 2017-05-10

👍12 ❤10

@vectorix ：是的。 ASP.NET Core 文档的第一页，ASP.NET Core简介说：

下一步
...
ASP.NET Core 应用可以使用 .NET Core 或 .NET Framework 运行时。有关详细信息，请参阅在 .NET Core 和 .NET Framework 之间进行选择。
...

它链接到一个页面，该页面非常清楚地表明您可以使用 .NET Framework（完整的）。

看在他妈的份上，那个比较页面甚至这样说：

.NET Framework 将继续成为许多现有方案的自然选择，因此，对于所有服务器应用程序，它不会被 .NET Core 取代。

CMircea 于 2017-05-10

👍26

就个人而言，让我高兴的只是说 BOBTRUES 将在 netstandard x 中，其中 x 甚至不需要定义。否则，如果您关心性能，您会说 netstandard 已经死了……

bencyoung 于 2017-05-10

5 天后，我们即将开始 BUILD 活动。

让我们等待，让微软（希望）发布公告并与大家分享他们的愿景和路线图

PabloAlarcon 于 2017-05-10

@CMircea ：感谢您指出。这确实很明显。似乎有必要保持与 .NET 桌面框架的兼容性，以遵循页面的文字和精神。

vectorix 于 2017-05-10

我们刚刚在 Azure 上托管的 .NET462 之上为 ASP.NET Core 1.1 客户端完成了一项大型工作。我们不得不走这条路，因为他们通过上传 MS Access db 将数据刷新到站点，然后我们将数据导入 Azure SQL。我们能做到这一点的唯一方法（这是一场斗争）是使用完整的框架。我真的不想让我不得不告诉我们的客户，如果幸运的话，这个解决方案只会得到 1 年、2 年甚至 3 年的支持。告诉他们他们需要更改整个流程以消除访问问题不是一种选择，我已经尝试了多年！

如果有更好的选择来读取 Access 数据库，或者它在某处的路线图中，那么我会很高兴。否则，这是令人担忧的。

dsyrett 于 2017-05-10

👍1

@bencyoung我认为最大的区别在于 JSON.NET 不是一个应用程序，它是一个库。我相信库作者的意图是针对 .NET Standard 以确保尽可能广泛的兼容性，而 ASP.NET Core 是一种应用程序模型。我的问题是，ASP.NET Core 的多少层将与 .NET Standard 兼容，以及针对 netcore 的目标是什么？我有针对 .NET Standard 编写的新代码，但有 ASP.NET Core 分层方面的参考，但可作为库使用。

话虽如此，没有什么可以阻止库作者针对 netcore 而不是 netstandard，但它们可能会降低大量潜在项目的兼容性，而 ASP.NET Core 限制了对（现在）特定运行时上运行的应用程序的损害。

Antaris 于 2017-05-10

据我所知， @Antaris ASP.NET 是一个库。 Kestrel 是应用程序。您可以在当前想要的任何应用程序中自行托管 ASP.NET Core 吗？

bencyoung 于 2017-05-10

@bencyoung公平点，我的措辞很糟糕。

我的意思是（如果我能找到_正确_的说法），您以一种特定的方式使用 ASP.NET Core（作为堆栈） - 运行 Web 应用程序。您可以根据应用程序模型以多种方式使用 JSON.NET 之类的库。考虑到 ASP.NET Core 的移动部分，Razor 之类的东西仍将基于 .NET Standard 构建，并且这些东西通常可以用于其他应用程序模型。那有意义吗？

不要误会我的意思，我并不是在为一种方法与另一种方法辩护，但我从从事一些新项目中受益，而不是根据未来与 netfx 的兼容性来集成/升级遗留代码库。所以我想从这个意义上说，我不能为提高兼容性的论点增加太多权重（netfx 上的 ASP.NET Core 2+）

Antaris 于 2017-05-10

@Antaris谢谢，虽然我不确定！我们在与 WCF 服务相同的进程中自行托管 REST API，以实现向后兼容性，在 Windows 服务内部......

bencyoung 于 2017-05-10

哇，微软做出了多么糟糕的决定。首先，.NET Core 将成为新的 .NET，然后微软决定，我们需要尽可能多地带回旧的 API。现在，他们通过使用完整框架启动 ASP.NET Core 项目，将信任 Microsoft 的人们抛在脑后。我每天都对 .NET 失去信心。 Golang 并不完美，但它每天看起来越来越有吸引力......如果有人没有注意到......它正在获得越来越多的牵引力。我认为微软可以利用 Java 社区无法在短期内完成任何事情，但 .NET Core 完全令人失望，过去 2 年我们或多或少都在踩水……而我们所做的一切换取它的是跨平台（现在谁在乎你可以在 Windows Nano 上的容器中运行 .NET）和大量复杂性（可笑的可怕工具，不支持 F#（VS），.NET 标准宾果游戏。）

更新：我在这里看到了一些反对意见，但很难与表情符号进行有意义的对话；）你不同意什么？

GiorgioG 于 2017-05-10

👎5 😄3 👍2

跨平台支持是我切换到 ASP.NET Core 的主要原因，我认为我并不孤单。但这并不是 ASP.NET Core 的唯一改进。还有更多，例如模块化结构，这当然是框架上非常需要的，多年来一直在增长。 Buildin DI 也是新的。

将旧的 4.x 框架与 ASP.NET 核心一起使用的可能性对我来说似乎是一个很好的折衷方案：像我这样的 OS/Linux 爱好者不会被迫使用 Windows。但是真正需要 Windows 的公司（比如 AD 身份验证）可以使用它们。我不明白微软为什么要打破这种良好的中间方式。尤其是现在，很多来自旧 4.x 框架的重要命名空间还没有移植到 ASP.NET Core。

DMW007 于 2017-05-10

@DMWOO7请不要混淆 .NET Core 和 ASP.NET Core。

MartinJohns 于 2017-05-10

请不要混淆 .NET Core 和 ASP.NET Core。

具有讽刺意味的。 😆

jnm2 于 2017-05-10

😄6 👍4 😕1

@MartinJohns我更新了我的帖子以使其更加明显。

DMW007 于 2017-05-10

@bencyoung

所以你会很高兴说 Newtonsoft.JSON 为它的下一个版本这样做，放弃对任何现有版本的支持一年的时间尺度？您对解析、IO 和高性能库开始放弃对 netstandard 和 .NET Framework 的支持感到高兴吗？

就我个人而言，我对此很好，因为我构建 Web 应用程序和服务以在容器中的 Linux 服务器上运行，除了我自己和我自己的用例之外，我不关心任何人，这就是我加入的原因这个线程。

不过说真的，我不希望 JSON.NET 放弃对netstandard的支持，但是看到有人发布了一个 Core.Json 库，它与 more-optimal-for 一起工作，我一点也不感到惊讶-web 开发netcore API。

markrendle 于 2017-05-10

👍2 👎1

欢迎使用 .NET 的 Python 3。自从几年前宣布 Core 以来，我一直有一种感觉，这种情况每次都会发生。

Eirenarch 于 2017-05-10

👍9

让 ASP.NET Core 以 netcoreapp2.0 为目标是最有意义的。 .NET Core 提供了一个全新的起点和在多个平台上运行应用程序的方法。试图拖拽所有为 Windows 创建的 API 只是等待发生的火车残骸。 Python 3 的类比很好，Python 3 也是如此。

glennsills 于 2017-05-10

好的，在阅读了该主题后，我提供了一些不同的观点，显然是一种边缘观点：

我不为生活（仍在学习）制作网站，有时我会为自己或小公司/组织制作一个更小或更大的网站。有时，人们会来寻求技术建议。
我从一开始就使用 ASP.NET，但我大多忽略了“Web 表单堆栈”并直接处理和编写 HTML——想想 Razor Pages。
我做过的任何与网络相关的事情总是在 IIS 上运行。跨平台支持对我没有兴趣，尽管我并没有被它冒犯。
我太小了，不在乎官方支持什么。
我通常不依赖 3rd 方库。

我希望任何关注 Microsoft 的人都会想到 .NET Core 可能会获得比 .NET Framework 更多的资源，最终 .NET Framework 最终可能会处于仅维护模式。此外，虽然添加了缺少的 API，但很明显，从来没有打算提供与完整的 .NET Framework 相同的功能。

ASP.NET Core 在 .NET Framework 上运行的事实使我能够站在开发的前沿，保持行业相关性并拥有所有很酷的新事物，同时仍然可以访问框架的完整功能集（以及操作系统）。我已经在 ASP.NET Core 中尝试了几个简单的网页，并且还计划创建一个更大的网页。实际上，我计划在 .NET Framework 上使用 ASP.NET Core 进行所有新开发。好吧，我想没有了。

让我回答一些问题（不分先后）：

为什么 ASP.NET Core 2.x 而不是 1.x
Razor Pages 绝对是。这就是我主要的工作方式。稳定性和其他人似乎称之为“成熟度”的东西将是另一个问题，尽管有人建议将修复程序向后移植。如果工具被拆分，我会认为它会产生很大的影响。
这意味着对我来说将它推迟到 3.x 就可以了。
为什么选择 ASP.NET Core 而不是 ASP.NET
好吧，鉴于这个话题，这是一个公平的问题。当您拥有完整的 .NET Framework 时，根据定义，ASP.NET Core 会为其增加价值。现代堆栈、标签助手、统一 API 和 MVC、最新功能。如果没有完整的 .NET Framework，就没有那么多了。确实，看起来回到 ASP.NET 对我来说是最好的解决方案。
新功能或兼容性？
100% 新功能。但是，将字符串切换为 UTF-8（和 4 字节字符！）或架构重构对我来说是兼容的更改。取出功能不是。
我使用 .NET Framework 的哪些功能
我担心的大问题：
_System.Windows.Media.Imaging_。绝对不是~~System.Drawing~。这听起来像是与 .NET Core 的一切背道而驰。由于这是一个长线程，引用@JimBobSquarePants和@mstum ：
> System.Drawing 尤其令人困惑和担忧。我无法理解为什么你会想要在任何平台上将该 API 移植到 .NET Core。它很难使用，在服务器上不受支持，并且缺少现代开发所需的许多关键功能（多线程、像素格式、ICC、EXIF、量化、索引 Png 等）。

不支持在 Windows 或 ASP.NET 服务中使用 System.Drawing 命名空间中的类。尝试从这些应用程序类型之一中使用这些类可能会产生意想不到的问题，例如服务性能下降和运行时异常。有关受支持的替代方法，请参阅 Windows 映像组件。

我所有的网络图像都使用 WIC。移植从未被支持的技术，而不移植多年来一直被推荐的技术会有点令人失望（尽管如果这是大多数客户的需求，这可以理解）。

_System.Windows.Xps_ 和 _System.Windows.Markup_。我在 XPS 中生成所有文件（从发票到运输标签）。在 XAML 和全功能数据绑定、XAML 布局（包括文本堆栈、分页、模板和带有触发器的样式等）中创建文档时，您可以获得设计时支持 - 非常酷。
_System.Reflection_ 用于检查程序集、生成文档等并填补框架空白。
其他已经提到的：
_WCF_ 和 _ServiceModel_，与政府的沟通就在这
_DirectoryServices.Protocols_ 和 NTLM 身份验证
SQL 中的空间类型
密码学
我使用但我相信可用的其他方法：电子邮件、ZIP 归档。

最后，这完全是一个商业决策。对我来说，没有完整 .NET Framework 的 ASP.NET Core 限制了我可以创建的内容，我目前没有令人信服的理由使用它。很高兴重新评估情况是否发生变化或我的生活取决于它。
但我认为我是否在平台上并不重要。流行的名字和大企业客户是否在场很重要。创建的应用程序是否最终出现在 Azure 中而我的没有，这很重要。所以我想我需要和任何让框架保持活力的东西一起玩。

这种变化是否使其保持活力和竞争力是另一个问题。不过公平地说，我相信它确实，正如上面有人所说，针对没有.NET Framework 背景的人。对于其他人来说，要么值得转换，要么不值得。还有像我这样的人认为可以两全其美。这个决定是突然的，甚至可能是不公平的，但在使用最新的开发技术时，这总是存在风险。发生在 .csproj 中，现在发生在 .NET Framework 中，我很确定它也会在未来发生。

PS。可惜这个“从未交流过”的填补空白的作用之前没有被指出。我当时支持 msbuild 项目系统，但如果 .NET Framework 在几个月后已经超出计划，我可能不会对此感兴趣（或者觉得我应该有发言权）。我认为做重大决定很好，迟到总比没有好，但如果目标受众是一致的，这将有所帮助。

miloush 于 2017-05-10

❤2

最后，这完全是一个商业决策。

问题是微软正在制造不确定性。大企业讨厌不确定性。 Microsoft 曾经是兼容性之王（好与坏，不是我的决定。）然后 .NET Core 出现了......破坏了兼容性......然后好消息，我们将添加一堆旧的 API。 ..现在我们有了这个 ASP.NET Core 2.0 中断。

大企业喜欢无聊、可靠的技术堆栈。初创公司不太关心，而且微软似乎无法决定他们想要取悦哪个群体。

GiorgioG 于 2017-05-10

👍9

@GiorgioG我不确定我是否真的理解为什么拥有现有应用程序的大企业会想要切换到 ASP.NET Core。它看起来更像是一种时尚之类的东西。

miloush 于 2017-05-10

👍2 👎1

@miloush我认为这更多的是为未来做准备。如果您将现有代码库缓慢转换到 .NET Standard / ASP.NET Core，但在完整框架下运行它，则您将代码定位为将来与 .NET Core 兼容，因此您不必制作巨大的，一次停止所有转换，当对旧系统的支持被放弃时。

现在企业无法做到这一点，因为将它们转换为 .NET Standard 是不够的，您要么必须完全喝掉凉爽的助剂，要么根本不喝。

Reanmachine 于 2017-05-10

👍3

@miloush - 假设他们在完整框架上使用 ASP.NET Core 1.1 启动了一个项目。他们永远无法迁移到完整框架上的 ASP.NET Core 2.0。这可以接受吗？对于在那条船上的任何人来说，这听起来都非常糟糕。

GiorgioG 于 2017-05-10

👍6

@miloush因为 .Net 核心更高效（我不想在这里列举所有的技术进步，你知道它们，合并的 API/MVC 控制器、标签助手、本地化支持等）并且因为企业确实在升级。他们通常不做的是大爆炸式升级，因为他们承受不起不连续性，他们通常必须以小增量进行。

对于一家初创公司来说完全不同，如果放弃对先前版本的支持，他们不会不在乎。他们没有遗产，他们没有这种问题。

popcatalin81 于 2017-05-10

@popcatalin81 - 所有这些点也可以通过完整的框架来达到，一个不与另一个冲突，问题是一个和另一个的开发速度，我看到 MS 非常急于发布一个微-在基准图表中看起来不错的服务框架，看起来已经成为一种痴迷。

adrianlmm 于 2017-05-10

👍5 ❤1

推荐观看：

“三个运行时，一个标准…….NET 标准：全部在 Visual Studio 2017 中”

在 Build https://channel9.msdn.com/的 45 分钟内有两个 Scotts 可能会提到什么？

benaadams 于 2017-05-10

@adrianlmm相关但不严格相关，我们停止喝微服务koolaid了吗？它增加了大量的复杂性（构建/部署/操作/故障排除/等），大多数公司不需要它们（有多少公司需要水平可扩展性来保证增加的操作复杂性？）我完全支持有限的上下文，但我们不需要 50 个微服务来做到这一点。

GiorgioG 于 2017-05-10

@GiorgioG我的问题更多的是他们为什么首先要迁移到 ASP.NET Core 1.1。好吧，我做到了，而且我确实觉得——这不是我最好的一天，这是肯定的。但是我没有一个很大的代码库，我必须迁移并且会等待事情如何解决，然后再进行更大的投资。我的意思是即使没有任何预算，我也会推迟在 ASP.NET Core 上开发更大的新网站，然后才能获得可用的工具，而且未来有点明朗——结果证明这不是一个糟糕的决定。（免责声明：我再一次不必在大型业务代码库或靠它生活时做这个决定，所以对我来说太赤裸裸了。）

我不是在责怪人们跳起来（我也做过小事），而且我绝对不想为对方辩护——如果 ASP.NET Core 永远支持 .NET Framework，我会很激动！

我不太了解的是，在 RTM 和新工具链要求 6 个月后，变化和不确定性成为问题的大公司是如何陷入这种境地的。

miloush 于 2017-05-10

@miloush我们已经“等待 .NET Core 解决”一年多了。在某些时候，人们实际上需要开始......并交付项目；）

GiorgioG 于 2017-05-10

@miloush他们想利用 ASP.NET Core 的改进，但仍然必须使用 .NET 库。官方表示您可以在 .NET 和 .NET Core 之间进行选择。现在他们突然陷入了一个非常糟糕的境地：他们无法升级到 ASP.NET Core 2.0 版，他们会卡在 1.x 版上。并且在某些时候，对 1.x 的支持即将耗尽——而且新功能也不会出现在 1.x 中。

MartinJohns 于 2017-05-10

@GiorgioG ，到目前为止，我已经将 .Net 核心用于一个新项目，并在另一个完整框架上迁移到了 Asp.Net 核心。两个活跃的项目。

并不是我不想到处使用 Net Core，我愿意，但事实上我还不能到处使用它！这就是问题所在。我们应该抛开一厢情愿，首先考虑现实世界......

popcatalin81 于 2017-05-10

👍5

@MartinJohns我明白了，我处于同样的情况。

miloush 于 2017-05-10

恐怕现在，如果它不支持完整的框架，我们即将推出的项目会给我带来很多麻烦，而pact-net-core就是其中之一。

garora 于 2017-05-10

别无选择，只能放弃 ASP.NET Core 和 MVC。放弃对 ASP.NET Core MVC 的支持

YetaWF 于 2017-05-10

😕6

至此，我们来到了 .NET 的越南。大胆出手微软，看看有没有回报。

GiorgioG 于 2017-05-10

别无选择，只能放弃 ASP.NET Core 和 MVC。放弃对 ASP.NET Core MVC 的支持
@shanselman现在决定这个还为时过早吗？是否有任何公告/帖子这么说？

garora 于 2017-05-10

我在 .NET Framework 上的 ASP.NET Core 1.1 中完成了几个新项目。不高兴它现在是一个死胡同。希望我在旧的 ASP.NET 中完成它们。

BowserKingKoopa 于 2017-05-10

Scotts 正在与 Build 进行一次谈话，可能是谈话中或谈话之后的一些消息。您可以在此处直播： https ://channel9.msdn.com/?wt.mc_id=build_hp

NickCraver 于 2017-05-10

👍7

感谢@NickCraver的分享

garora 于 2017-05-10

典型的微软。
经过近 3-4 年的时间，他们无法开发出像样的浏览器。
近 2 年 - 没有生命周期 > 1 年的任何未来希望的框架。
而已！。
大拇指向下，事实不会改变。

dvbava 于 2017-05-10

👎18 👍3

免责声明：我已经阅读了很多，但不是上面 500 多条评论中的_all_。

让我烦恼的是，MS 一直表现得好像我们应该升级并问“是什么阻碍了你？”

妈的，别妄想了！ 😡 .NET Core 还没有准备好替换 .NET fx。不是今天，不是一年后！

这就是让我（我在 .NET fx 上运行的 ASP.NET Core 1.1 项目）回归的原因：

我需要金钱和时间来进行迁移以实现零业务改进。真的很难从管理层那里得到。
需要进行大量测试......零业务改进但真正的回归风险。
我们必须与其他公开COM api 的企业服务集成。我讨厌它，但别无选择。 @shanselman建议在 .NET fx 上创建一个 out of proc 服务并“处于一个痛苦的世界”。对不起，不，不会那样做。
EF是我仍在使用 fx 的主要原因。 MS 把你自己的东西弄清楚，然后你会和我们谈谈迁移。 EF Core 远未准备好取代 EF 6。
Oracle DB 提供程序不支持 Core。更糟糕的是：他们宣布计划仅将他们完全托管的提供程序移植到 Core，这有很多限制，例如不支持 Oracle 高级队列。
我们使用了许多3rd 方库，其中一些已经迁移，一些还没有（现在还是曾经？）。

@davidfowl
您的评论让我觉得 .NET fx 正在慢慢过时……那么您是否打算在 fx 中永远不支持 HTTP/2？
很抱歉，您需要将大部分工作移植到 .NET fx，该平台并没有死。如果我想从 WPF 应用程序执行 HTTP/2 怎么办？
我不在乎是否更快地向 .NET Core 提供了改进，或者某些非关键改进是否仅限于 Core。但 .NET Core 不会很快取代 .NET fx。

今天在 .NET fx 上构建 Web 应用程序的 MS 指南是什么（因为我显然无法在 .NET Core 上这样做）？

不是我渴望新功能（我不），而是我想在一个活的平台上，而不是一个死的平台。得到维护并获得必要更新的东西——即使速度很慢。

jods4 于 2017-05-10

👍29

另外微软，考虑一下：

如果 ASP.NET Core 2.0 在 .NET fx 5.0 上运行，这是我可以及时组织的升级。
何时发布 .NET 5.0 并不重要——即使它比 ASP.NET Core 2.0 晚得多——我从 .NET 4.6 升级需要多长时间也没关系。 _我有升级之路和未来。_

如果 ASP.NET Core 2.0 _only_ 在 .NET Core 上运行，那么我就陷入了死胡同。
尽管我愿意，但在接下来的_年_内，我看不到从 fx 到核心的迁移。原因见上文。

jods4 于 2017-05-10

👍5

@Kukkimonsuta有上面最好的总结之一。就我而言，使用 Core-on-netfx 的项目取得突破的决定因素是 EF Core v EF6，以及其他尚未与netstandard兼容的 OSS 工具集。

在这次讨论中，一个令人不安的事情是@davidfowl和他的受访者互相“谈论过去”：他对哭泣和哭泣的回应是不流血的“好吧，但是你真正需要什么 API？” 这是一个值得称道的重新聚焦谈话的尝试，但他（很可能在不知不觉中）隐瞒了一个关键问题。他（和@shanselman ）的另一个回应是，这是保持 ASP.NET Core “尽可能快地向前发展”所必需的。又是一个值得称道的目标，但又隐藏了一个关键问题。（这两个隐藏的问题通常都是OSS的核心“隐藏问题”。）

这也不仅仅是一个心理/情感问题，正如@MisterGoodcat在他试图弥合分歧时所主张的那样。 @GiorgioG更接近目标，他认为“不确定性”是“大企业”不喜欢的东西。

问题的根源在于成本。由不确定性驱动的成本，以及与不断变化的发展环境保持同步的成本。这些不只是打击“大企业”，它们打击了每个开发人员。也许不是金钱方面的（预先），但肯定是时间，压力，因此能够迅速而自信地执行（是的）业务问题的解决方案。

让我们再次考虑“您真正需要哪些缺失的 API？ ”的挑战-响应问题，通过庞大的项目工具链追溯这个问题，并可能回到第三方库。在考虑修复它的成本之前，仅仅回答这个问题是昂贵的。

“尽可能快地前进”怎么样？同样，这很好，但是随着每一次“向前发展” ，开发人员都不得不跟上变化的步伐。这不仅会影响我们工作所带来的学习/使用差异，还会影响学习曲线以及寻找和培训新人才的费用。

最令人不安的是一些人的态度，即依赖于旧的、不可移植的库的“边缘情况”不是一个值得考虑的问题。诚然，这不是任何人都想被困的地方，但解决技术债务并不是非利益相关者的日程表上应该承担的成本。

现在，虽然这些成本并非微不足道，但我们都知道并期望它们在这项工作中发挥作用。事实上，就迁移到 .NET Core 而言，我认为大多数人都期望即使我们没有被迫这样做，这样做也是正确的。问题：

现在推动这一点会破坏我们大多数人正在使用的“摊销时间表”（有时长达数年），无论是在积极采取行动方面，还是在解决技术债务（不可移植代码）方面。
推动它的方式（“我们这样做是为了你好。”）对于未来的稳定性来说并不是一个好兆头：我们怎么知道未来会为我们做出什么样的决定？

当@shanselman按下按钮以开源 ASP.NET 时，我正在拉斯维加斯的主题演讲中。从那以后，MS 一直只向 OSS 迈进。但这始终伴随着一个问题：除了 OSS 的好处之外，“坏”是否也会渗入微软的伦理？换句话说，我们在交易中失去了什么，我们得到了什么？我认为这是我们开始看到的地方。

另一个旁白：我很欣赏@markrendle的想法，对于每个工具/库维护者实际上从netfx向前迈进，这一举措将是一个“踢裤子”。但是，有两个问题：首先，时间表就足够了。如果发布了一个 N 年版本周期的公告，其中 M.0 版本将看到 ASP.NET Core 被普遍吸收到 .NET Core 中，那将是足够的“棒”。我将是第一个对我使用的工具的维护者使用它的人（可以这么说）。其次，有了这个公告，（在深吸一口气之后，看看对消极情绪的反应会带来什么），特别关注 ASP.NET（MVC 或 Core）的工具现在很可能无需担心netstandard compat 并直接跳转到 .NET Core，进一步划分了 .NET 格局。

marcrocny 于 2017-05-10

👍9

仅供参考 .NET Core 2.0 预览版已发布：
https://www.microsoft.com/net/core/preview

MJomaa 于 2017-05-10

👍1

阅读 Asp.net 核心预览版的发行说明，我找不到任何关于不支持完整 .Net 框架的信息。

它已经完成了，不是吗？

PabloAlarcon 于 2017-05-10

韦尔普，我的一个恐惧得到了证实。

几乎直接引用了 MS Build 演讲：“NuGet 中 70% 的所有内容都与 .NET Standard 2 API 兼容……唯一不兼容的是 WinForms 和 WPF，因为并非所有平台都存在这些内容.但其他一切都在那里。没有重新编译。只是工作。

这是令人难以置信的误导。

scottsauber 于 2017-05-10

😕10 👍1

@PabloAlarcon这是您正在寻找的变化：

https://github.com/aspnet/Mvc/commit/1c5e4176069ea20671e1738ac599e544633f47ce

放弃对net46作为平台目标的支持，大多数项目文件都有这个：

-    <TargetFrameworks>net46;netstandard1.6</TargetFrameworks>
+    <TargetFramework>netcoreapp2.0</TargetFramework>

我认为大多数人希望这种改变是：

-    <TargetFrameworks>net46;netstandard1.6</TargetFrameworks>
+    <TargetFramework>netstandard2.0</TargetFramework>

Reanmachine 于 2017-05-10

👍1

哦，谢谢，但我指的是刚刚发布的 Preview 1 的发行说明： https ://github.com/dotnet/core/blob/master/release-notes/2.0/2.0.0-preview1.md

PabloAlarcon 于 2017-05-10

@PabloAlarcon我认为这里更大的问题之一是提前完全缺乏关于这个问题的沟通，以至于现在即使是 Build 的演讲者也引用了关于生态系统的误导性信息/统计数据。

他们都声称大多数库是netstandard2.0兼容的，这意味着它们应该（最终）在任何地方运行，但这种变化实际上意味着如果你的项目甚至在 MVC 方向上呼吸，你只能在 .NET Core 运行时运行它。

Reanmachine 于 2017-05-10

👍5

这些是 .NET Core 2 预览版发行说明，而不是 ASP.NET Core 2 预览版发行说明。此更改将在这里： https ://github.com/aspnet/home/releases/2.0.0-preview1

而且我想它应该在那里的已知问题和重大更改列表...但是单击那里唯一可用的链接会给出一个没有结果的 github 列表

bbarry 于 2017-05-10

我的错，我读了两页但复制了.net核心的一页。

还是一样，看不出来。

PabloAlarcon 于 2017-05-10

@marcrocny你的措辞更好，为什么我认为“什么图书馆？” 问题比我能解决的实际问题，所以谢谢。我不需要新的闪亮的弹幕，我需要在合理的时间范围内的新功能，并且它们是稳定的，更重要的是，得到一段时间的支持。

10 美元说 HTTP2 永远不会完全满足 .Net。

boeremak 于 2017-05-10

猜猜是时候为 ASP.Net Core 社区分叉了。

popcatalin81 于 2017-05-10

👎6 🎉3

切换回完整的 .NET Framework 和NancyFX可能是少数人的选择，这取决于他们首先切换到 ASP.NET 核心的原因。

dbus0 于 2017-05-10

👎4

@dbus0问题是，一旦你离开了微软框架的神圣之地，你最终会得到一个支持它的库的微小生态系统（与 ASP.NET 相比）

如果您打算放弃 ASP.NET 转而使用 Web，最好选择非 .NET 技术堆栈 IMO。

GiorgioG 于 2017-05-10

👍1

有人能说出 aspnet core 2.0 无法实现的功能列表吗？

evilz 于 2017-05-10

伙计们，你们正在扼杀曾经美丽的 .NET 框架。你管理 .NET 的 linuxesque 方式只会让一切看起来像一个巨大的黑客。 MS-dev 中的一切都开始看起来很业余，不连贯，每个团队/产品都单独运行。 BETA 中的所有内容，InProgress 中的所有内容，一个大巨人，让我们尝试看看会发生什么，我们开玩笑说，我们承诺不会这样做......，你真的需要那个吗？为什么？等等。如果我们想要这样的东西，我们会投资 PHP 和 Linux 来讨论库 X 不能与内核 Y 一起工作，因为包 Z 不兼容，所以我们需要重写所有应用程序只是为了好玩。

另外，我讨厌团队隐藏在诸如“行动得更快”、“探索机会”之类的营销口号后面，这些口号只是将业务目标隐藏在虚假的技术原因后面。我什至开始在生态系统中到处看到一些“这是开源的 - 自己修复”的回复。我的理解是，我们不能再信任很多 MS 技术，尤其是 .NET Core，它不知道它的去向和原因。我已经非常沮丧，但是不兼容版本的疯狂以及 .NET Core 中任何级别和开发状态的重大变化（ASP.NET Core 改变了 RC 的所有内容？哦，拜托......）但事实上，作为开发人员和商业用户，我不能代表我的公司推荐或决定投资 Core 只是为了开始无休止地讨论 Core 1.0 如何不支持 Core 1.1 但我们无法升级它，因为它破坏了这个或那个但我们会喜欢升级到 2.0，因为我们需要只有 2.0 才有的新功能，而且……什么？你在开玩笑吗？

而且，这种方法是否会破坏某些东西或了解人们实际使用的命名空间或功能以引入新的后期更改以支持人们可能想要的功能并不重要。您正在通过我看到的最糟糕的行为使事情短路，这不是早期的计划，因为我们可以发布一个新的 XYZ 版本并告诉人们升级。如果他们不能，出于任何原因，运气不好。即使我们在 v8.0 上工作，我们也会“支持”v1.0，只是您将没有 v8.0 的任何功能，因此我们的支持基本上包括在您抱怨并表示生活艰难时拍拍您的背。

我不敢相信过去两年我们放弃了多少 MS 技术。我从没想过我们能做到这一点，因为我们自 1998 年以来一直是 Microsoft 商店。哎呀，在我们所在的地区，当它是“.NET 的东西”或“它是 Windows 的东西”时，我们总是会被雇用（不问任何问题 - 它是Windows -> 打电话给他们）但是今天当我必须为一个新项目选择一种技术时，我总是想知道保持.NET框架是否明智，一般来说。可以肯定的是，在阅读完本文后，我们对 .NET Core 的所有投资至少会停止，直到我们了解其中的情况。我们绝对没有意愿也没有时间向我们的客户解释为什么我们需要重写那个或这个，因为 .NET Core 1.1 与 2.0 不兼容，或者我们需要创建一个单独的小型项目，该项目需要有人维护来托管一个库我们需要的，但它与框架的“旧”版本兼容，其中“旧”表示 3 个月前发布的版本。而且我们仍然需要升级，因为“旧”版本将被维护（可能）但不会收到新功能。

您必须知道，这种方法使我们重新考虑 .NET 框架作为一个整体，重新考虑 .NET 框架意味着重新考虑 Windows。重新考虑 Windows 意味着重新考虑我们是否需要微软。我们不应该去寻找 GitHub 或一些不起眼的论坛来了解 vNext 将支持哪些功能并将它们与 vCurrent 进行比较以了解我们是否可以开始开发针对 BETA 或 Alpha 版本以与 vNext 兼容，因为我们需要它特定功能，因此在此阶段使用旧版本进行开发毫无意义，但我们的风险是针对非最终版本进行开发，并且可能（并且将会）改变，只是在几个月后再次开始这种疯狂。那不是“敏捷”，那是有很多空闲时间的孩子。

我一直都知道我会想念盖茨，但我从没想过我也会想念鲍尔默。做的好各位。

tbprince 于 2017-05-11

👍6

在我看来，完全切换到 .NET Core 为时过早。目前，许多第 3 方框架和库不支持 .NET Core。以 NServiceBus 为例。请至少在 ASP .NET Core 3 之前支持 .NET Framework...

profabe 于 2017-05-11

预览 1 期
此 ASP.NET Core 2.0 预览版仅支持 .NET Core 2.0 SDK。 我们的目标是在 .NET Standard 2.0 上发布 ASP.NET Core 2.0，以便应用程序可以在 .NET Core、Mono 和 .NET Framework 上运行。

当团队在 Build 之前解决他们的最后一个问题时，发现 ASP.NET Core 2.0 的预览版使用了 .NET Standard 2.0 之外的 API，从而阻止了它在 .NET Framework 上运行。 因此，我们限制了 Preview 1 仅支持 .NET Core，因此它不会破坏开发人员将 ASP.NET Core 1.x 应用程序升级到 .NET Framework 上的 ASP.NET Core 2 预览版。

benaadams 于 2017-05-11

🎉60 👍9

那里倒退不错。

因此，该线程中删除 .NET Framework 的所有反馈和“理由”只是为了预览？

DamienDennehy 于 2017-05-11

😄8 👎7 👍7

值得注意的是，这里也没有宣布改变主意……

willdean 于 2017-05-11

👍7

@benaadams

我们的目标是在 .NET Standard 2.0 上发布 ASP.NET Core 2.0，以便应用程序可以在 .NET Core、Mono 和 .NET Framework 上运行。

“我们一直在与东亚交战”

Aaronontheweb 于 2017-05-11

😄22 ❤4

这令人欣慰，但上面来自官方 ASP.NET Core 成员的一些评论传递了一个_非常_不同的信息。

我想要一份关于 .NET 框架的 ASP.NET Core 中期未来的官方声明。

MS 是否致力于维护与 netstandard 兼容的 ASP.NET Core？
不仅仅是 ASP.NET Core 2.0 版本（不一定是 4.7）。

jods4 于 2017-05-11

👍9

在这里谈论一个令人头疼的情况。到底是怎么回事？：思维：

tuespetre 于 2017-05-11

👍1

那里倒退不错。
因此，该线程中删除 .NET Framework 的所有反馈和“理由”只是为了预览？

嘿，不要在这件事上胡闹。他们对 ASP.NET Core 应该是什么有一个愿景，已经给出了很多反馈，并听取了反馈。

感谢 ASP.NET 团队👍

JamesNK 于 2017-05-11

👍58 🎉16

@davidfowl

我们最后一次在 .NET Framework 中更改字符串和数组是什么时候？

在 .Net Framework 4.6 中，两者都适用。这是全新的 .Net Framework 4.7 之后的一个小版本，不到两年前。

我不确定字符串和数组在.Net Framework 中是否像您所说的那样难以更改。

svick 于 2017-05-11

@詹姆斯NK

已经给了很多反馈，并听取了反馈

是吗？至少有一些反馈抱怨沟通不足。现在我们有来自 MS 的人在这个线程中说一件事，最近的一篇博客文章说另一件事，没有关于变化或未来是什么的信息。

我希望至少有来自 MS 的人出现在这个线程中，并说他们改变了对 ASP.NET 2.0 的想法，并且在未来版本中删除 .Net Framework 仍然存在，但他们会尽快通知我们他们知道的更多（或者无论实际情况如何）。

svick 于 2017-05-11

👍7

我希望至少有来自 MS 的人出现在这个线程中，并说他们改变了对 ASP.NET 2.0 的想法，并且在未来版本中删除 .Net Framework 仍然存在，但他们会尽快通知我们他们知道的更多（或者无论实际情况如何）。

在他们的防守中（并不是说我认为这处理得很好），整个团队几乎都在构建。我相信我们很快就会在这里听到一些消息。几天后，没有人的生活会因为这个决定而改变。

mattnischan 于 2017-05-11

👍6

嘿，不要在这件事上胡闹。

今天和昨天，我在伪危机模式下与我的团队讨论了这将在未来 12 个月内对我们造成的技术战略的影响和变化，结果却被告知“糟糕，我们很糟糕！”。

我欢迎这种变化，我很感激我们被倾听。虽然我不想成为一个鸡巴，但我对这方面的交流感到_生气_。

DamienDennehy 于 2017-05-11

👍9 😕3

我们已经将字符串确定为我们希望在 .NET Core 中尝试解决的主要问题之一，有很多想法，但其中之一是默认将字符串设置为 utf8（大量兼容问题，但请在此处关注我）。
我们想要修复的另一件事是能够获取廉价的数组/字符串切片，任何连续内存。我们添加了跨度并且正在查看缓冲区来代表这一点。这可能意味着 String 和 Array 实现了新的接口，使获取需要 0 分配的切片成为可能。
这导致 String 上的新方法允许拆分而不是每次都分配数组。
这会导致采用 Span 的 Int、UInt 等 (TryParse) 的重载和跨度.
这导致了采用 Span 的新编码例程.
缓冲和跨度让您以统一的方式表示内存，我们希望升级网络堆栈以允许传递占用 Span 的预固定缓冲区或缓冲区.
Kestrel 将在 2.x 时间范围内实现 HTTP2（目前针对 2.1），这需要 SSL 流上的新 API 来执行 ALPN（https://en.wikipedia.org/wiki/Application-Layer_Protocol_Negotiation）。
.NET Core 上的 Http 客户端支持双工流式传输，它可以通过单个非 websocket http 请求在信号器中通过 http 实现流式传输端点。
我们从 HttpClient 和 System.Net.Http 分叉了标头解析器实现并将它们重命名（https://github.com/aspnet/HttpAbstractions/tree/d1d9bceff56cb44a194ae36923ce687e5e353006/src/Microsoft.Net.Http.Headers），以便我们可以改进它们并让它们同时支持 .NET Framework 和 .NET Core。 .NET Core 有一份这些改进的副本，因为没有必要改进它们（我们无法使用它们），所以没有恢复。
有一堆新的线程原语需要新的 API，如果我们能够使用它们，它们将点亮新的场景（https://github.com/dotnet/corefx/issues?q=is%3Aopen+is%3Aissue+ author%3Adavidfowl+label%3Aarea-System.Threading），这些只是我个人提交的一些内容。

RIP 现代平台。如果 asp.net 核心团队从上面收到了解决方案。

YuriiPovkh 于 2017-05-11

今天和昨天，我在伪危机模式下与我的团队讨论了这将在未来 12 个月内对我们造成的技术战略的影响和变化，结果却被告知“糟糕，我们很糟糕！”。
我欢迎这种变化，我很感激我们被倾听。虽然我不想成为一个鸡巴，但我对这方面的交流感到很生气。

您对他们听取社区的意见并（似乎）改变路线感到不安？您将时间花在从未最终确定的事情上既不是社区也不是微软的错。

johnduhart 于 2017-05-11

👍4

好消息！

simonmurdock 于 2017-05-11

我希望这并不意味着我们现在默认错过了 utf8 字符串以及@davidfowl谈到的其他好东西（如果在 .NET Core 上运行）

danielcrabtree 于 2017-05-11

👍4

由于“不支持 ASP.NET Core 2.0 的 .NET 桌面支持”计划最终被取消，我认为我们现在可以关闭此线程（但如果您希望我重新打开它，请不要犹豫联系我）。

我要感谢大家抽出时间参与这个话题；毫无疑问，它帮助微软的负责人意识到，如果不咨询社区或衡量他们单方面决定对整个生态系统的实际影响，他们不能在最后一刻默默地采用如此重大的突破性变化。

尽管我们都有不同的意见，但最重要的是就这一变化进行真正的讨论。这显然是一个巨大且史无前例的成功（150 名参与者和 600 多条消息，哇！）

看到这样一个伟大的社区在行动真是太棒了，我为成为其中的一员而感到自豪：call_me_hand：

kevinchalet 于 2017-05-11

❤56

@davidfowl @DamianEdwards @shanselman谢谢。这让我的生活变得轻松了很多，我们现在可以毫无疑问地推进我们的迁移计划，还有很多其他人也可以。我知道这对于 ASP.NET 团队来说并不理想，但我真诚地认为这是平台发展的最佳举措。

这个线程处理得非常好，即使有一些不太有效的评论。您很少会看到数百条评论在一段时间后包含任何有用的内容（ @davidfowl ，您太棒了）。

我期待与 3.0 进行这个讨论，当我希望平台能够达到这一点时，放弃支持是一个更容易的选择，从而大大减少用户落后。我期待着帮助实现它。

NickCraver 于 2017-05-11

👍50 ❤22 🎉12

这个结果似乎很好。我相信我们很快就会制定出路线图，并计划将所有内容都转移到核心 - 只是，在一段时间内，每个人都提前知道它:)

gulbanana 于 2017-05-11

也想留下我的想法......很高兴看到 ASP.NET 团队在听取了社区反馈后能够迅速改正，我相信这是 .NET 框架和最终繁荣的 .NET 未来的最佳策略.NET Core 本身的采用我预计大多数采用将来自现有的 .NET 开发人员，其中许多人将能够继续将他们现有的代码库迁移到 ASP.NET 的新开发模型。

我也不责怪犯了错误，尤其是在公开开发时，重要的是我们可以从中学到什么。 OSS 的最大优势之一是能够及早获得反馈，因此您可以就项目的未来及其用户的最佳课程做出明智的决定，我相信 ASP.NET 团队能够在这里做到这一点。我希望它还重申信息对于您的项目的方向、愿景和路线图的重要性，它们如何构成早期采用者和您最忠实的利益相关者的战略决策的基础，以及在提出基本原则时让您的社区参与的重要性可能影响他们对您平台的现有和未来投资的更改。

最后 9 年我一直在 Github 上积极开发，这是我参与过的最活跃的线程，大多数评论能够保持深思熟虑和礼貌，这预示着 .NET 的未来有多少开发人员仍然关心。 NET 并渴望采用 ASP .NET Core 并跟随 MS 进入 .NET Standard 和 .NET Core 将实现的令人兴奋的多面未来。未来激动人心的时刻！

mythz 于 2017-05-11

👍20

感谢收听微软！

GiorgioG 于 2017-05-11

👍3 👎1

@davidfowl @DamianEdwards @shanselman谢谢。
感谢微软

ikourfaln 于 2017-05-11

👍1

天啊！我错过了什么热辣辣的烂摊子？好吧，无论最终结果如何，我只希望它加强而不是削弱 dotnet 生态系统。我可以尝试创新并需要在某些时候切断过去，但那些成为下一个 Python 2 vs 3 的参考都太真实了。尽管我个人并没有受到我自己的项目的影响，但我很高兴在这里看到所有开发人员的支持。所有这些人都对该产品产生了浓厚的兴趣，并详细举例说明了它如何影响他们，这证实了这个社区的强大程度。感谢大家的关心和保持这个社区的活力！

wizarrc 于 2017-05-11

👍1

大家干得好！
.NET 上 OSS 的好消息！！

schotime 于 2017-05-11

👍3 👎1

@davidfowl @DamianEdwards @shanselman感谢您听取反馈。另外，感谢您亲自在我们的组织内开始讨论我们如何以 .NET Standard 为目标以提高平台可移植性。我希望我们可以找到一种方法，将我们在 WinForms 应用程序和 ASP.NET Core 应用程序之间共享的所有库定位到 .NET Standard 2.0，这样我们实际上就可以在 .NET Core 上运行我们的 ASP.NET Core 产品将来。

millman82 于 2017-05-11

👍4 👎1

3.0版再见？

boeremak 于 2017-05-11

积极的一面：我很高兴你决定改变这一点。让我作为开发人员的生活变得更加轻松，我有理由投入时间和精力在 .Net 中学习和开发，这是一个很好的理由。

那谢谢啦。

boeremak 于 2017-05-11

好吧，我不认为放弃对完整 netFx 的支持是一个错误。相反，唯一的错误是 ASP.NET Core 一开始就支持完整的 netFx。

换句话说，ASP.Net Core 永远不能支持完整的 netFx。它应该是专门为 .Net Core 构建的 Web 框架。

ASP.Net Core 应该在 .Net Core 之上，它实现了 .Net Standard 的某个版本，它应该与完整的 netFx 无关。

只要 .Net Core 可以在其上运行，ASP.Net Core 应用程序就可以在任何平台/操作系统上运行。但这只是关于运行的能力，而不是支持所有特定于平台的功能。如果真的需要特定于 windows 的功能，他应该使用支持 windows 的多目标 nuget 包，或者他应该使用 ASP.Net 代替。

所以我认为团队试图做的事情会纠正这个错误。但不幸的是，你们成功地阻止了他们。

顺便说一句，也许将“ASP.Net Core”更改为“ASP for .Net Core”，将“ASP.Net”更改为“ASP for .Net Framework”可能会让一切变得有意义。你们需要的实际上是“ASP.Net Standard”或“ASP for .Net Standard”。

jarenduan 于 2017-05-11

👎15 😕4 👍2

@davidfowl @DamianEdwards @shanselman也加入我的声音，感谢您的决定。

.NET Framework 对我们来说非常重要，除非我们所依赖的库也在那里，否则我们永远不会超越它。

感谢您加入社区。

pjmlp 于 2017-05-11

👎1 👍1

欢迎来到真正的开源

tinonetic 于 2017-05-11

好消息！ :) 我希望微软现在知道，对可靠的未来的信任对我们许多人来说是关键，他们不会很快再犯这个错误。

FransBouma 于 2017-05-11

老实说，我不确定为什么你们都已经庆祝了。博文与本期 Fowler 和 Edward 的陈述相矛盾，他们尚未撤回或纠正他们的陈述。这篇博文是由另一个人 Jeffrey 撰写的。在本期中，有人提到放弃 .NET 支持是经过深思熟虑的决定。在博客文章中，他们提到“发现”缺乏支持。博客文章中没有提到他们在社区的反斜杠之后改变了他们的计划。

所以对我来说仍然缺乏清晰度。团队中不同成员的相互矛盾的陈述。

@DamianEdwards @davidfowl ：您能否就这个问题澄清一下？

@PinpointTownes ：也许你应该重新打开这个问题，因为它不像你想象的那么清楚。

MartinJohns 于 2017-05-11

👍16

我和@MartinJohns 在一起。这是否意味着 ASP.NET Core 并没有从@davidfowl谈到的 .NET Core 的快节奏开发中获利？

henkmollema 于 2017-05-11

我也持怀疑态度。目前，车辆已经向后倾斜并朝着正确的方向行驶，但驾驶员没有正确掌握事情的证据比以往任何时候都更有力。

这里发生的事情、新闻稿/博客中发生的事情以及我们必须推断的内部发生的事情之间的不一致是可怕的。在客户领域，我们正在努力做出决定，在未来 X 年内信任 MS 与我们的业务，这是试图赢得信任的一种令人震惊的方式。

看看历史：

秘密做出的错误决定（坏）
有点令人讨厌的试图证明它的合理性（有点好，有点坏）
逆转错误决定（好）
试图掩盖前三个步骤（令人震惊）

很遗憾，Build 是一个过于光鲜的 wankfest，因为昨天在两个 Scotts 的节目中做的明智的事情就是扔掉 powerpoint，把六个高级 .NET 人放在中间的塑料椅子上在合理地解释他们的立场的同时，在舞台上并有男子气概地接受狗屎。

相反，他们完全忽略了在房间里肆虐的大象，现在显然试图假装一开始什么都没有发生过。

错误的决定和逆转是开发过程中很自然的一部分，而使用 OSS，您可以看到它们——这很好。公司掩饰不是。

.NET 是 MS 销售 Azure 的工具，这是一个比仅仅选择开发框架更需要长期信任的命题。本周的信任建设进展如何？

willdean 于 2017-05-11

👎4 👍1

我在这里第二个@MartinJohns ：他们不能瞄准netstandard2.0，否则天会塌下来，现在他们可以了。（他们当然可以，没有技术原因不能，但根据@davidfowl和@DamianEdwards的说法，这是需要的）。他们现在将如何做到这一点，现在已经决定了什么？我知道这是 //build 和所有的，但他们并没有人手不足，没有人可以来这个线程并解释一下。还是我们都必须向我们最喜欢的 Microsoft 员工发送消息并通过反向渠道询问？我真的希望不会。

FransBouma 于 2017-05-11

昨天在两个 Scotts 的节目中，明智的做法是扔掉 powerpoint，让半打 .NET 高级人员坐在舞台中央的塑料椅子上，在合理解释他们的立场的同时，有男子气概地接受狗屎。

@willdean观看 Build 主题演讲或 Scott² 会议的绝大多数人一开始对这件事一无所知。这是完全可以理解的，他们不想把这个事故拖到光明中，如果这只是一个错误，让成千上万的开发者和这个帖子一样困惑，他们还是决定重新做决定。

让我们给团队一些松懈，并希望在构建之后有一个好的解释/事后分析：smile：

khellang 于 2017-05-11

👍15

绝大多数观看 Build 主题演讲或 Scott² 会议的人一开始对这件事一无所知。

这是一个公平的观点。

willdean 于 2017-05-11

@FransBouma他们可以支持netstandard2.0，但在polyfills，交叉编译和额外代码方面会很痛苦。在某些新功能到位之前，某些功能实际上也可能无法实现，例如 http2。

但这并非不可能。这只是很多额外的工作，每个人都不愿意做。

整个核心生态系统是创新和传统支持之间的平衡行为。我们需要足够的传统支持来最终将大多数东西放在核心上，但也需要足够的创新来使核心成为一个有吸引力的平台。

我希望有一个好的事后分析，但在这里解决它就足够了。发表一篇博文只会让 99% 的人感到困惑，因为他们不知道这是一个问题。

hallatore 于 2017-05-11

👍1

@hallatore “这只是每个人都不愿意做的大量额外工作。”
我能感觉得出你。我个人宁愿明天开始绿色，但没有人给“我”这个选项......因为你知道，现实......

我们不要忘记 ASP.Net 是一个“生态系统”，其中包含 CMS、第 3 方库、组件、软件，其构建时间超过 17 年。你不能只是把球放在你的生态系统和社区上，然后说我们真的想使用花哨的字符串，即使这意味着把你全部抛在后面……你“就是不能”……这是你能做的最糟糕的事情一个支持社区。

想要利用进步，那么无论如何，构建平台特定的代码路径并利用。这样，随着时间的推移，用户群将转向利用平台差异。但在任何情况下，忽视大部分生态系统的“需求”都是明智的选择。

popcatalin81 于 2017-05-11

@hallatore

它们可以支持 netstandard2.0，但在 polyfill、交叉编译和额外代码方面会很痛苦。在某些新功能到位之前，某些功能实际上也可能无法实现，例如 http2。

不。它只是代码，C#，编写然后运行。当我读到他们显然不能在 .net full 上做的事情的清单时，我真的不得不笑，因为它不得不与 .net full 做分手。这只是政治。我们局外人必须在 .NET 上编写非常快的代码，必须处理这些 api，并且必须充分利用它。我们这样做。我们也解决了他们必须解决的相同问题。他们也可以。他们只是不想那样做。但坦率地说，我太老了，并且已经与 Microsoft 肥皂打交道太多次，无法再认真对待这一点。让他们保持雷德蒙德的内部政治，不要让用户（我们！）因此而受苦。正如我们之前已经做过很多次一样，请注意。

我希望能有一个好的事后分析，但这足以在这里解决它。发表一篇博文只会让 99% 的人感到困惑，因为他们不知道这是一个问题。

是的，博客文章不是正确的地方。这个线程是他们现在如何解决它的理想场所。

FransBouma 于 2017-05-11

👍5

@FransBouma

由于对 asp.net core 和 kestrel 的研究，Core 包含了许多新功能。这不是 C#，而是代码使用了完整框架中不存在的东西。

正如@davidfowl所说。他们为大多数当前的东西提供了 polyfills。但是他们开始看到他们甚至无法填充的东西。这意味着他们很可能需要放弃一些东西或对整个框架进行更改。将新功能纳入完整框架与核心所需的工作是巨大的，并且需要更长的时间框架。

然后我们回到平衡行为。我们应该因为完整的框架而限制 core，还是应该 core 能够以比 asp.net 更高的速度进行创新？

我非常理解他们为什么只想支持核心。从纯粹的技术角度来看，支持完整框架增加了他们现在需要考虑的大量内容。但是生态系统和社区并没有为仅核心做好准备（正如我们清楚地看到的那样），其代价是更复杂的 asp.net 核心开发。

hallatore 于 2017-05-11

@hallatore如果您想破坏兼容性，请提前宣布并宣布迁移路径。您投资的一种或另一种方式为您的用户提供迁移路径。

这或多或少是拥有用户的代价，拥有用户不是烦恼，而是一种责任。

我不认为我们在争论是否需要更多的工作来支持更多的平台。它是。成本更高，代码路径更复杂等等。你能摆脱这个成本并选择单一平台吗？好吧，这里的大多数答案，意思是社区的声音，都说不是这个时候，生态系统还没有准备好。这意味着负责任的事情要做找到某种中间立场的解决方案。

popcatalin81 于 2017-05-11

👍3

@hallatore

由于对 asp.net core 和 kestrel 的研究，Core 包含了许多新功能。这不是 C#，而是代码使用了完整框架中不存在的东西。

好吧，那就移植过来吧。他们两个都拥有，我不明白为什么会有任何问题。请注意：他们可以通过简单地创建 netstandard2.0 库来移植代码，甚至更好：创建针对 .net 核心中更快实现和 .net full 中较慢实现的 shim（例如来自 nuget 的库）。

我在运行时生成 IL 以从我的 ORM 中的数据读取器中获得超快的预测。我不会把我的手举在空中“做不到！”，因为没有人会为我解决它。我敢打赌，您也遇到过类似的问题，您只需深入研究并使其正常工作，因为没有其他人会拿起标签。他们现在也必须这样做。

他们为大多数当前的东西提供了 polyfills。但是他们开始看到他们甚至无法填充的东西。这意味着他们很可能需要放弃一些东西或对整个框架进行更改。将新功能纳入完整框架与核心所需的工作是巨大的，并且需要更长的时间框架。

抱歉，但他们不能“填充”什么东西？是的，他们在 .NET full 上搞得一团糟，而且在某些地方性能很糟糕，为了让事情像竞争对手一样表现，他们必须做出艰难的选择。好吧，解决它。不是在某个角落，而是解决核心问题：在 java 上他们也可以解决它，他们的性能令人惊叹，他们通过不破坏任何核心 API 或创建第二个平台来做到这一点。只是软件：保持界面不变，解决后端。是的，这需要做很多工作，但是您认为快速完成 ORM 等操作是否可以在一夜之间完成？ :) 或者让 web 服务运行良好，以便它可以运行大型公司的关键业务逻辑？不，这需要努力。没关系。

这里房间里真正的大象是完整的.NET 以及它是如何管理的。或者更好：那里缺乏管理。我知道他们不能引入重大更改。那么，然后引入不会中断的更改。如果您查看 Win32，他们从未引入任何重大更改。东西很简单。是的，事情在增长，宁愿把所有东西都删掉的那群人会一天天增长，但这无关紧要：我们都处理的软件有一些曾经很重要的部分，现在不那么重要了，但我们不能把它们抛在后面/删掉它们也不要改变它们，因为它会破坏人们的代码。

然后我们回到平衡行为。我们应该因为完整的框架而限制 core，还是应该 core 能够以比 asp.net 更高的速度进行创新？

它已经被提到过几次，但我不明白为什么你不能以同样的速度在完整的框架上进行创新。我们都必须在完整的 .net 上创新我们自己的软件。我知道在字符串支持方面存在瓶颈，但是如果您需要一个不复制的字符串，那么创建一个并继续前进。是的，您可以在接下来的十年中了解它有多丑，或者您可以介绍该课程，在其上构建快速的东西并取得进步。我最近在 win32 上做了相当多的 C++/x64 汇编程序，如果你看到他们在那里重新定义了多少次字符串并且显然没有人打赌，我们在 .net 上会很好。我的意思是，我们已经有两种字符串类型（字符数组和字符串）。

我非常理解他们为什么只想支持核心。从纯粹的技术角度来看，支持完整框架增加了他们现在需要考虑的大量内容。但是生态系统和社区并没有为仅核心做好准备（正如我们清楚地看到的那样），其代价是更复杂的 asp.net 核心开发。

信不信由你，我完全明白他们为什么要完全脱离 .NET。我的意思是，我自己的运行时/API 在某些地方已经 14 岁了，我昨天也想从它的某些部分中脱颖而出。但是我也知道我不能，因为我的客户会因此受到伤害，这对他们和我都不利。当你创建一个平台/运行时/API 时，你必须考虑到在你做的第一个版本之后，你就走上了一条你无法摆脱的道路：你的 API 从那一刻起就是一成不变的。你可以弃用它的废话，但你不能删除东西，这样它的用户就会崩溃。 Angular 1.x->2.x，python 2.x->3.x，足够的例子。

FransBouma 于 2017-05-11

👍7 ❤3

您不能在 netstandard 包中打包对 BCL 原语的更改。如果要更改 System.String 和 System.Int32，则需要不同的 BCL。

而且您无法以相同的速度在完整框架上进行创新，因为对完整框架的每次更新都是对之前版本的就地更新，数十亿行代码取决于每种可能的功能组合（包括未记录的特征）。您可以在 .NET Core 上更快地进行创新的原因是，您可以让针对所有不同版本的 .NET Core 的应用程序都在同一台服务器上独立运行，每个服务器都有自己的运行时副本。这就是它的全部意义所在。他们构建它是为了更快地迭代。现在他们想利用能够更快地迭代的优势。

我个人认为错误是首先从 ASP.NET Core 支持完整的 .NET。从一开始就应该是彻底的休息。

markrendle 于 2017-05-11

👍12 👎2

我个人认为错误是首先从 ASP.NET Core 支持完整的 .NET。

老实说，他们需要 2.0 工具和兼容 shim 才能使这个远程可行，所以 IMO，这是他们最早可以做到的。延迟只是让人们延迟转换，延迟对微软大喊大叫他们多么讨厌他们的用户。你知道，无论何时他们这样做——无论有什么警告——人们都会为此失去理智。

坦率地说，这个帖子的大部分内容让我为 .NET 社区感到非常难过。

bradwilson 于 2017-05-11

👍6 👎5

您不能在 netstandard 包中打包对 BCL 原语的更改。如果要更改 System.String 和 System.Int32，则需要不同的 BCL。

是的，我知道，这不是我暗示要说的。我看到有些人从这个角度误解了我的帖子，但这不是我的本意。如果可以的话，我想在这里举一个关于主题的例子：在我的 ORM 中，我也使用字符串连接来创建查询字符串。对于每个 ORM，这是一个巨大的开销。使用默认的字符串类在一定程度上是有帮助的，但是在所有的复制过程中都会变得丑陋。所以我介绍了一些特定的类，这些类可以极大地减轻或完全避免这种复制。这有缺点，因为您不能在字符串类型足够的地方使用它们，也不能将它们与所有采用字符串实例的 API 一起使用。但是，您_可以_在您自己最需要它们的地方使用它们：通过您自己的代码在热路径上。

这_by far_并不理想，如果可以避免这种情况，显然应该这样做。然而，生活的混乱和我们释放的东西永远留在那里。您无法更改已经存在的内容，因此您必须处理_处理这种情况_，解决方案之一是引入新类型和使用这些类型的新代码。这种方法在所有主要的操作系统 API 中使用了很多年，虽然它很糟糕，但它是一种行之有效的前进方法，而不是停留在僵局的过去。

FransBouma 于 2017-05-11

另一种行之有效的前进而不是陷入僵局的方法是接受仇恨者无论如何都会讨厌和破坏事物（参见Angular 2+和Python 3，它们都做得很好）。

markrendle 于 2017-05-11

@NickCraver我向你打赌 100 美元，无论何时他们最终突破，无论是 3.0、2.2 还是 23.5，花生画廊中的服装都会像今天一样哭泣和撕裂。

markrendle 于 2017-05-11

另一种行之有效的前进而不是陷入僵局的方法是接受仇恨者无论如何都会讨厌和破坏事物（参见Angular 2+和Python 3，它们都做得很好）。

当然。但是，两者都有后果：“OS API”方法很丑陋，并且多年来导致一个带有许多死胡同的大型 API。 'angular/python' 方法打破了人们的升级路径并分裂了社区（不知道 angular 世界有多碎片化）。鉴于 ASP.NET 核心，我不知道哪种路线更好。从技术角度来看，Python 路线当然更可取。从稳定性的角度来看，它正在扼杀 iMHO。

FransBouma 于 2017-05-11

几乎 Angular 世界中的每个人都会“哦，是的，那是 _much_ 更好”并开始迁移。 Python 是目前增长最快的语言之一，而 Python 3 正在推动它。

markrendle 于 2017-05-11

我个人认为错误是首先从 ASP.NET Core 支持完整的 .NET。从一开始就应该是彻底的休息。

显然，这个想法可以节省一些成本，但这与 MS 建立其完全主导地位的方式完全相反：

Windows 运行 DOS 应用程序
32 位 Windows 运行 16 位 Windows 应用程序和 DOS 应用程序
64 位 Windows 运行 32 位和 64 位应用程序
.NET 应用程序在发布时可在所有相关操作系统上运行

这些都是非常困难的技术挑战和极其昂贵的妥协，但它们让整整一代需要使用计算机完成工作的人放心，微软大致上是长期支持他们的。

从技术上讲，很难不回顾所涉及的内容，例如 Win32/Win16 互操作故事或在 Win3 -> Win95 -> WinNT 上运行 DOS 应用程序，并想知道大人是否在一段时间前离开了大楼。

willdean 于 2017-05-11

👍10

@markrendle

Angular 世界中的几乎每个人都会“哦，是的，那好多了”并开始迁移。

您真的想将 Angular 与 .NET 运行时进行比较吗？大多数人都希望立即迁移到 .NET Core。但实际上他们做不到。要么没有大量的依赖项，要么风险太高，或者成本太高。

MartinJohns 于 2017-05-11

👍2

@markrendle

Angular 世界中的几乎每个人都会“哦，是的，那好多了”并开始迁移。 Python 是目前增长最快的语言之一，而 Python 3 正在推动它。

我认为您在掩盖 Python 3 已经推出 9 年的事实，并且最终它正在成为用于新项目的默认 Python。但是，我的 Mac 运行最新的 OSX...带有 Python 2.7.12。我的 NAS 也一样。

Angular 也是如此——如果您正在编写一个可以在几个小时内移植到 Angular2 的极小演示应用程序，那就太好了。在现实世界中，我们仍在使用 Angular 1，因为迁移一个 2 到 3 年的大型应用程序并非易事。移植需要时间和金钱，而企业需要理由。

GiorgioG 于 2017-05-11

👍8 😕1

是否可以像IA-32 执行层一样创建软件驱动程序？

stefan2410 于 2017-05-11

😄1

@布拉德威尔森

坦率地说，这个帖子的大部分内容让我为 .NET 社区感到非常难过。

你会不会因为微软最初让我们走到这一步的错误步骤而责备他们？ .NET Core 应该是一个彻底的突破。然后它不是。他们将其命名为“.NET Core”这一事实意味着您知道…….NET 的核心就在那里吗？什么是.NET？在过去的 15 年里，它一直是 .NET Full Framework。如果微软想要彻底决裂，它应该为这个东西选择一个新名称，坚持自己的立场，而不是回去重新引入所有旧的 API，让人们在旧世界和新世界之间做出选择。他们现在放弃的决定会使项目处于以下三种情况之一：

您在完整框架上使用 ASP.NET MVC，并且可以在完整框架上移植到 ASP.NET Core 1.X，但在此之后，在您迁移到 .NET Core 之前，您都是 SOL。
您在完整框架上使用 ASP.NET Core 1.X，您必须移植到 .NET Core 才能迁移到 ASP.NET Core 2.0
您正在 .NET Core 上开发 ASP.NET Core。

假设微软已经向前发展并且不支持完整框架上的 ASP.NET Core 2.0，那么情况 1 和 2 中的人们没有明确/现实的路径将现有应用程序迁移到 ASP.NET Core 2.0。情况 1 的人可能会理解，但情况 2 的人有理由生气。情况 2 可能是一个小团体，但这是我们正在谈论的微软，而不是一个人维护的一些小型开源项目。企业/人民的生计依赖于这些系统。如果他们不能依赖微软，那么下次你可以打赌他们不会使用这个平台。信任很重要。在考虑使用 Microsoft 堆栈的商店中 - 反对者会将其用作警示故事。

我将此问题归咎于 Microsoft 糟糕的 .NET Core 消息传递/营销/命名。你不可能一直取悦所有人，但成功的一半是从一开始就设定正确的期望。

GiorgioG 于 2017-05-11

👍16

@MartinJohns我正在回复之前的评论。

markrendle 于 2017-05-11

@markrendle为什么笑？请解释。如果“API 几乎相同”，那么像字符串这样的基本更改可能可以通过这种方式处理。并且如果 API 有变化，只有在有人想使用它时才可以是一个单独的包，在 .Net Core 中？

stefan2410 于 2017-05-11

好家伙 - 想想 Internet Explorer。微软_finally_杀了它。当然，他们等了很长时间，以至于他们的替代浏览器 Edge 可能仍然在市场上诞生。每个人都只使用 Chrome。仍然有很多地方人们使用 IE，因为升级他们的应用程序以使用现代浏览器没有商业价值，而且仍然有人抱怨微软如此缓慢地拔掉插头。

ASP.NET Core 是微软根据我们在过去 15 年左右所学到的东西来取代 .NET 的尝试。使开发人员可以轻松地继续使用 .NET Windows 框架，同时提供新的 ASP.NET Core 功能，这听起来很像 IE 9。最好将 .Net 4.x 的支持与它们所搭载的操作系统的支持生命周期联系起来继续前进。

glennsills 于 2017-05-11

👍1

@glennsills我错过了 IE 和 Edge 之间的相似之处。 IE 仍然随 Windows 一起提供，因为有些东西在 Edge 中不起作用。 Edge 不支持我工作的 VPN 我并不生气——这很好……它是一个不同的浏览器。它甚至有一个完全不同的名称，所以我没有任何先入为主的观念认为它应该支持 ActiveX ;)

GiorgioG 于 2017-05-11

👎1 👍1

@glennsills你指的是什么错误？

popcatalin81 于 2017-05-11

@markrendle “Angular 世界中的几乎每个人都去“哦，是的，那好多了”并开始迁移。“

通过选择这样的坏例子，你真的在损害你的论点。如果有的话，他们处理过渡的方式使他们失去了领先优势（他们当时以很大的优势领先）。
与 python 3 相同 - 碎片化扼杀了他们多年来的任何动力。

dahauns 于 2017-05-11

👍9

所以，我只是想在这里理解一些东西。
我正计划将使用 .Net Remoting 的旧 Asp Web 表单应用程序转换为 Asp .Net 核心 MVC 应用程序。我的计划是继续使用 .Net Remoting，直到我们有机会从系统中删除这些垃圾。听起来，如果我以 Asp .Net Core 2.0 为目标，我将无法做到这一点？但是，如果我以 Net Core 1.1 为目标，我会吗？

wbuck 于 2017-05-11

@wbuck截至昨天，故事是它仅在 ASP.NET Core 2.0 的单个预览版本中，您将无法针对完整框架进行构建。大概在 2.0-preview-2 中，他们将恢复此功能。因此，目前您可以针对 1.1 而不是 2.0-preview-1。

谁知道更长远的未来是什么——显然完整的框架最终会被放弃——时间表是任何人的猜测。

willdean 于 2017-05-11

@popcatalin81好吧，如果你想在多个平台上运行，访问 COM 对象肯定是一个错误。如果您只打算在 Windows 上运行，但如果您想要跨平台，那么有很多这样的事情可能不是“错误”。想想 AspNET 与 IIS 的耦合。当时还可以，但随着时间的推移，它使堆栈变得非常复杂（即使在 Windows 上也是如此），并且使得在其他 Web 服务器上运行应用程序变得很痛苦。 ASP.NET 中默认缺少依赖注入，这使得单元测试（如控制器）成为真正的拖累。这不是一个“错误”，而是时间前进的一个例子，人们理解了一种更好的做事方式。

@GiorgioG - 是的，这就是我的观点。您可以在 Windows 10 上的 IE 和 Edge 之间进行选择，但您必须_选择_。你没有在 Edge 中获得 IE 功能，这是故意的——让 IE 和 Edge 功能在一个进程中同时工作将是一团糟。此外，未来对 IE 的支持仅限于错误修复。如果微软在 10 年前就这样做了，Edge 对 Chrome 的竞争力将比现在强得多。所以我认为微软应该在相当长的一段时间内继续支持.NET Classic，但更多的是一种错误修复模式。 Asp.Net Core 应该专注于跨平台的易于开发和性能。

glennsills 于 2017-05-11

有没有官方宣布取消？

pantonis 于 2017-05-11

@pantonis

有没有这方面的官方公告？

不，那里没有。不同的团队成员有相互矛盾的陈述。 @DamianEdwards和@davidfowl在这个问题上表示，放弃支持是一个深思熟虑的决定。 Jeffrey 在 ASP.NET 博客文章中写道，对 .NET 的支持将继续。但他们并没有互相提及。

MartinJohns 于 2017-05-11

嗨，大家好，

这次我没有跳到问题线程上，但我对纠正信息和方向所花费的时间非常满意。

我知道最初的决定是在最后一刻做出的，以便在 BUILD 之前使一切正常。说明您打算让它运行 .NET Standard 2.0 也非常令人放心。

再次感谢 .NET 团队的快速反馈，尽管有所有无用的评论，但我们仍在努力满足我们的需求。

非常感激。

MaximRouiller 于 2017-05-11

👍2

@MartinJohns哦，男孩.. 那么谁是正确的？

pantonis 于 2017-05-11

@wbuck

您未来对 .NET Remoting 的使用象征着承诺人们向后兼容所带来的问题。由于各种原因，远程处理没有成功，但因为人们过去使用过它（公平地说，因为微软有人告诉他们这是一个好主意）他们仍然想使用它。通过 WEB API 访问 ASP.NET Core 应用程序中的信息非常简单，您可以从非常古老的 .NET @@frameworks 中调用它。

正如我的一位刻薄的同事曾经说过的那样，“我们需要停止构建新的遗留应用程序”。构建支持 .NET Remoting 的 ASP.NET 服务器应用程序就是这样做的。

glennsills 于 2017-05-11

@pantonis坦率地说，不知道。许多人在本期中跳槽并立即将博客文章视为对本期中所述决定的回复，因为它是在稍后发布的。但我认为本期和博文中的声明是独立发表的，我们仍然没有明确的声明。

MartinJohns 于 2017-05-11

👍1

@pantonis最新的是博文中的官方公告

https://blogs.msdn.microsoft.com/webdev/2017/05/10/aspnet-2-preview-1/

预览 1 期
此 ASP.NET Core 2.0 预览版仅支持 .NET Core 2.0 SDK。 我们的目标是在 .NET Standard 2.0 上发布 ASP.NET Core 2.0，以便应用程序可以在 .NET Core、Mono 和 .NET Framework 上运行。
当团队在 Build 之前解决他们的最后一个问题时，发现 ASP.NET Core 2.0 的预览版使用了 .NET Standard 2.0 之外的 API，从而阻止了它在 .NET Framework 上运行。
因此，我们限制了 Preview 1 仅支持 .NET Core，因此它不会破坏开发人员将 ASP.NET Core 1.x 应用程序升级到 .NET Framework 上的 ASP.NET Core 2 预览版。

benaadams 于 2017-05-11

👍2

@benaadams但是该博客文章中的声明与此处的声明没有任何意义。在博客文章中，他们只是提到它已“被发现”并且他们限制了“预览 1 支持”。在这个问题上，他们一直提到别的东西。他们没有提及博客文章中的讨论。

如果我们能在本期的博文中得到官方认可，那就太好了。或者让博文承认这里的讨论。一些东西让我们知道这些不同的人都知道彼此的陈述。

MartinJohns 于 2017-05-11

这篇博文是正式的交流，它明显取代了我们在这里进行的非官方社区讨论。如果它不完全匹配，那么，我相信我们都了解企业沟通的紧迫性，并且向正确的受众讲述正确的故事可能比技术上的正确更重要。

没有必要试图让特定的人吃掉他们的话或其他东西 - 重要的是所选择的方向似乎是一个好的方向，我们可以安全地推断出它对我们的反馈做出了回应。

gulbanana 于 2017-05-11

👍10

我希望微软会发表声明消除混乱。加油，MS你可以的！！！

pantonis 于 2017-05-11

@pantonis @MartinJohns

我只能非正式地确认这一点，因为我不是 MS。
昨天的博文就是向前的计划，asp.net core 的工作人员非常符合它。

tl;dr：这是前进的计划： https ://blogs.msdn.microsoft.com/webdev/2017/05/10/aspnet-2-preview-1/

hallatore 于 2017-05-11

@pantonis官方公告是官方声明。

MaximRouiller 于 2017-05-11

陈述？

pantonis 于 2017-05-11

@PinpointTownes ：也许你应该重新打开这个问题，因为它不像你想象的那么清楚。

完成😄

kevinchalet 于 2017-05-11

@pantonis只是上面的一些评论。

https://github.com/aspnet/Home/issues/2022#issuecomment -300774201

MaximRouiller 于 2017-05-11

我希望微软会发表声明消除混乱。加油，MS你可以的！！！

公平地说，他们这周都忙于在一种强迫性的超级兴奋状态下腾跃而起，无法在这里浪费时间。鉴于曾经给出的对 .NET Core 的每一种解释都只会降低人们对世界的理解程度，也许最好还是听天由命。

willdean 于 2017-05-11

👎9 😄1

只是为了让读到这里的人更清楚......

如果最近的官方公告与此线程中的任何内容相矛盾，我们应该将公开的官方公告视为覆盖之前在此线程中所说的内容。

官方博文 > GitHub评论

它没有写在任何地方，但对我来说，这条规则已经存在了很长时间。

MaximRouiller 于 2017-05-11

👍2

@MaximRouiller

如果不是这样，那么@benaadams可能会知道。
几个小时前，我还与@davidfowl进行了交谈。公告是正确的。

编辑：本公告： https ://blogs.msdn.microsoft.com/webdev/2017/05/10/aspnet-2-preview-1/

hallatore 于 2017-05-11

@hallatore哪个公告？在 Jeffrey 或其他人的 ASP.NET 博客文章上？

pantonis 于 2017-05-11

放手吧。

声明是 ASP.NET 2.0 预览版 1 不支持 .NET Framework；但是他们计划在那之后支持它。天空不再坠落。

事后继续抱怨；可能会证明他们较少参与，较少分享想法，较少参与早期阶段的人，因此在更晚的阶段通知人们；具有更多临床分析的反应；当它也更难改变方向时。

如果你指责某人在你看来做出了错误的决定；然后他们会根据您的反馈改变主意；然后你会因为改变他们的决定而嗤之以鼻——你认为这会对未来的关系产生什么影响？它会很快变得功能失调。

更新更开放的MS；直接与开发人员和客户互动是令人兴奋的。请不要尽管您的行动将其关闭，并让一切都必须先通过公关部门的批准。这对任何人都不好。

更专业一点，考虑我们如何共同前进，以建立一个更好的生态系统。

benaadams 于 2017-05-11

👍34 ❤12 🎉2

@benaadams您将清晰沟通的愿望与投诉混淆了。到目前为止，这并不是要赶走任何人，而是希望他们进一步参与并消除混乱。你说他们根据我们的反馈改变了主意——这很好。但是博客文章没有提到这一点，所以这纯粹是你的假设。

这一突破性的变化没有被宣布。显然恢复的决定没有被宣布。我不希望减少参与，但希望更多参与。

MartinJohns 于 2017-05-11

👍7

@MartinJohns在公告中，您谈论现在和现在。

不是你是怎么走到那一步的。事实正是@benaadams所说的。

^在此处插入让它去 GIF ^

MaximRouiller 于 2017-05-11

👎1

@benaadams同意。尽管在一段时间内（即在 // build之后）提供了一些更多的技术信息，这可能是一件好事需要彻底休息。我看不出为什么应该在这个线程中和非正式的开发人员对开发人员的其他地方进行此操作。恕我直言，它可以让我们更深入地了解未来计划现在对 aspnetcore 2.0 的期望以及现在在这个时间范围内无法完成的事情，因此必须推迟。这也将有助于重新获得潜伏/仅阅读线程（并得出他们的结论......）的人们以及仍然有疑问的人们的信任。

FransBouma 于 2017-05-11

👍1

由于我们已经进行了几天很长的很好的讨论，我也希望在这个线程中发布“官方”公告，而不是突然沉默并被指向博客上的公告而没有提及这个讨论.

这并没有改变这样一个事实，即如果公告是正确的，这当然是个好消息。

razzemans 于 2017-05-11

👍1

对此感到抱歉，但我只是想澄清一下我对此的理解

以上图为例，我们是否真的以一种或另一种方式说 ASP.NET Core 的未来实际上并不是因为速度慢而位于 .NET Standard 层上，而是让 ASP.NET Core 位于 .NET Core 上？无论未来版本是 2.0 还是 3.0 等。

例如：-
.NET 核心 -> ASP.NET
还是仍然是 .NET Standard -> .NET Core -> ASP.NET Core

lilpug 于 2017-05-11

@lilpug这种图表说明了我的（不受欢迎的；-）关于解释只会让事情变得更糟的观点。 “.NET 标准”不是库，并且 ASP.NET Core 不应位于与 .NET Framework 对等的盒子中。

该图基本上是错误的，您应该忽略它。

willdean 于 2017-05-11

👍8

嗨@willdean你能提供一个更合适的更好的例子吗？

但老实说，我用它作为一个例子，不是将 .NET Standard 指出为库，而是更多的继承位置，把术语放在一边，我仍然想知道我的观点在我的想法中是否正确？

lilpug 于 2017-05-11

你能提供一个更合适的更好的例子吗？

不，我认为它违背了图表中的表示，或者至少它违背了我所见过的每个图表的作者的能力。即使@shanselman （一位完美的沟通者）写了一篇试图解释这一切的文章，它也会以一堆“术语准确性”来礼貌地说出来。

所有将“.net 标准”放在包含一堆代码库的图表上的尝试都注定要失败，因为它是 API 规范，而不是库，因此它的存在与库是正交的。

willdean 于 2017-05-11

👍2

ASP.NET 团队应该接受维护 ASP.NET 的负担，恕我直言，它根本不是 Angular。他们还应该考虑代表 Microsoft 发言的负担，虽然这在形式上可能不是真的，但在形式上肯定是正确的，这也意味着 ASP.NET 团队所做（或未做）的事情会在整个整个生态系统，并直接或间接反映 Microsoft 的优先事项。

一个简单的例子是对 AD 的支持：我不知道这到底是怎么被认为是可选的。或者更好，我知道，因为 AD 肯定是前互联网时代的遗物，而且迟早会被淘汰，但事实是，如果 Microsoft/DNF 甚至不考虑将 AD 移植到其官方的 ASP.NET Core 框架（除了一个模糊的承诺，它可能会在夏季之前添加......），信息是微软本身在边缘化技术。除了大多数 Microsoft 产品都需要 AD 才能工作，那么在 Microsoft 认为 AD 支持不那么重要的情况下，我有多大信心使用 AD 构建新的虚拟化集群？除非您还添加以下内容，否则这肯定是错误的信息：从现在开始，停止将 AD 添加到您的基础架构中。这就是我所说的微软的发展是以一种不连贯的方式发生的意思。

ASP.NET 团队在此线程中了解到，当他们提出某些事情时，人们会召开危机前的紧急会议，疯狂地寻找信息并认为他们做出了错误的选择。这就是现实世界中发生的事情，因为 ASP.NET 是一项核心技术（双关语），而不是一个简单的库，如果一切正常，您可以忽略它。因此，您需要稳定性并且还需要改进，因为这就是您使用核心技术的方式。

另一个愚蠢的例子：流行的 IdentityServer4 声明他们将只支持 ASP.NET Core 1.1，所以如果有人有一个 Core 1.0 应用程序，他们无法转换他们应该做什么？当他们的版本是……什么…… 4 个月大时，您认为告诉他们应该转换以避免使用旧框架是否公平？这取决于他们？绝不。只有在实际上不可避免时才提供重大更改取决于您，因为风险是分散开发人员，并且从中期来看，只是迫使人们切换。

老实说，这种回溯并不能解决任何问题。我知道开源 .NET 是最糟糕的选择，而且主要暗示着微软的退出。正如我之前在这个线程中所说的那样，.NET 现在基本上是一个支持 Azure 的工具。

并不是说开发人员不想接受这种变化（或者讨厌，就像有人说的，就像我们是小学生讨论你的头发颜色一样）：他们接受了，但老实说，微软并没有把它的重心放在这个选择上，而是利用这种变化来追求其业务目标。我们知道支持完整的 .NET 框架是可能的，这就是政治。这里的商业评论和评论比技术评论更重要，因为我们可以解决每一个技术问题。如果这个帖子没有告诉你问题不在于我们是否有 UTF8 字符串，而是人们依赖这些技术谋生，老实说......

对 ASP.NET 团队来说，这是否有太多的责任？可能是。如果是这样，让这些决定交给一个“超级团队”来负责整个生态系统和平台。

我什至不知道如何在 GitHub 上进行讨论。

tbprince 于 2017-05-11

👍11 ❤6

@willdean好的，让我们以不同的方式“不在图表中”:)，

例如，如果我在 .NET Standard 2.0 中构建了一个库，那么 ASP.NET Core (.NET Core) 是否会支持（未来）如果是这样，那么它意味着“NET Standard -> .NET Core -> ASP.NET Core " 如果不是，则意味着 .NET Core 正在脱离并且不会利用 NET Standard 的基础。

lilpug 于 2017-05-11

@lilpug如果一个库是 .NET Standard，它可以被上层的任何东西使用。

因此，.NET Framework、.NET Core、Xamarin、Mono、Unity 等可以使用 .NET Standard 库，如图所示。

.NET Standard 是库在理想情况下应该遵守的标准，以允许最大可能的覆盖范围（版本越低，覆盖范围越大）。

上面的层是应用模型；它的exes /可执行文件是什么。它们是最终的终点。

所以你有一个 .NET Framework exe，它只能在 Windows 上运行。

Xamarin 可执行文件；将在 iOS、Android、OSX 上运行（尽管您需要为每个运行 3 个不同的可执行文件）。

.NET Core exe 可以完全移植并与 dotnet 启动器donet my.dll一起运行，或者为特定平台 Windows、Linux、MacOS、Tizen 创建专门针对的可执行文件，并且仅在这些平台上运行；并且您可以从相同的代码为所有特定平台输出目标可执行文件（自包含）；如果你想这样做。

例如，如果我在 .NET Standard 2.0 中构建一个库，ASP.NET Core (.NET Core) 是否会支持它

是的; 情况总是如此。即使 ASP.NET Core 库确实专门针对 .NET Core，所以它们只能在 .NET Core 上使用；您仍然可以在 ASP.NET Core 中使用 .NET Standard 库。这个问题中提出的任何事情都没有影响到这一点。

benaadams 于 2017-05-11

👍10

@benaadams 非常感谢你，这更有意义。

未来的最终结果是放弃对 ASP.NET Core 中 .NET 完整框架的支持，无论是在下一个版本还是未来版本中，我想知道未来的库是否开始在 .NET 标准上“如果可能”构建它们而不是 .NET Framework 4.6+，如果这有助于未来证明我们更多地使用 ASP.NET Core 以及使其与其他层更兼容。

lilpug 于 2017-05-11

谈话是明天，所以我们必须拭目以待。

https://channel9.msdn.com/Events/Build/2017/C9L18

adrianlmm 于 2017-05-11

@lilpug

好的，让我们以不同的方式“不在图表中”:)，
例如，如果我在 .NET Standard 2.0 中构建了一个库，那么 ASP.NET Core (.NET Core) 是否支持它，如果不是，则意味着“NET Standard -> .NET Core -> ASP.NET Core”这意味着 .NET Core 正在脱离并且不会利用 NET Standard 的基础。

将 .NET 标准视为一个接口，它由 2 个类实现，一个在 .NET core 中，一个在 .NET full 中。也存在其他实现，例如在 xamarin 和 UWP 中。请注意，这不是物理接口，而是这里的隐喻。现在，如果您编写以该接口为目标的代码，您可以在运行时使用该接口的实现，无论是.net core 中的类还是.net full 中的类。

因此，使用 netstandard2.0 定义了一个 API 接口，该接口在各种平台上都有实现，例如 .net core、.net full、xamarin、uwp。因此，您可以编写一个与 netstandard2.0 兼容的库，这意味着它只使用该标准 API 定义中的 API，这意味着该库将在所有实现该接口的平台上运行。

ASP.NET core 2.0 与 netstandard2.0 兼容意味着它们将仅使用 netstandard2.0 中的 API，这意味着 ASP.NET core 2.0 将在所有实现了 netstandard2.0 的平台上运行。

（编辑）drats， @benaadams打败了我。

FransBouma 于 2017-05-11

👍4

@lilpug如果您制作 .NET Standard 库并且只使用 .NET Standard 库，那么一切都很好，并且您可以面向未来。

提出的问题是那些使用库的人，这些库目前不兼容 .NET Standard。所以这些库不能在 .NET Core 2.0 上运行

随着 ASP.NET Core 库成为 .NET Core 2.0 库，这意味着它们无法在 Full Framework 上运行（尽管它们仍然可以使用 .NET Standard 库）。

benaadams 于 2017-05-11

👍1

我感谢大家的反馈，我主要担心的是第一个线程是这样开始的：-

今天早些时候，大多数 ASP.NET Core 2.0 包都更新为针对 netcoreapp2.0 而不是 netstandard1.* 和 net4*

这让我担心我们不仅在谈论放弃 .NET Full Framework，而且还在谈论 .NET Standard 的基础层。

谢谢你帮我解决这个问题，我很感激👍

lilpug 于 2017-05-11

对于尸检，我非常有兴趣澄清一些事情：

当团队在 Build 之前解决他们的最后一个问题时，发现 ASP.NET Core 2.0 的预览版使用了 .NET Standard 2.0 之外的 API，从而阻止了它在 .NET Framework 上运行。

当您以netstandard1.3和net46目标时，例如 Kestrel（其他软件包具有类似的目标）。您如何最终“使用 .NET Standard 2.0 之外的 API”？

AFAIK， netstandard2.0是netstandard1.3 _and_ net46的超集，所以我很难看到你如何最终会遇到使用 API 阻止你运行的情况在 .NET 框架上。该项目将如何编译？好的，也许您使用带有一些附加 API 的单独包，但为了引用这样的包，它需要支持所有目标框架。

肯定有一些关于诱饵-n-切换和引用程序集等的东西。我没有到达这里，或者博客文章中的评论只是假装这从来没有发生过的一种方式？ 😕

此外，为什么甚至需要在预览之前急于进行此更改？ .NET Framework 不是测试矩阵的一部分吗？

khellang 于 2017-05-11

👍6

@adrianlmm谢谢哥们。

这应该结束关于是否支持它的评论，这会导致更多的混乱。正如你所说，让我们等待事件

请让它成为这里的最后一条评论，这样任何第一次看到这个帖子的人都不必阅读所有这些长帖子，而是查看活动的链接。

pantonis 于 2017-05-11

@pantonis

https://www.youtube.com/watch?v=xz6OGVCdov8

jbogard 于 2017-05-11

😄3

@khillang

也许@benaadams知道。
我很确定他有一些拉取请求（可能已经合并？），其中包含在核心之外不起作用的东西。

hallatore 于 2017-05-11

@khillang引发此问题的 PR 与博文中的声明完全不一致。

如果事实确实如博客文章中所述（最后一分钟实现，临时更改），那么为什么会在此更改中删除大量#if NET46代码？

willdean 于 2017-05-11

😕1 👍1

为什么会在此更改中删除大量#if NET46代码？

@willdean是的，这是一个很好的观点。如果您只是更改目标框架，那么隐式定义就会消失，代码（来自已编译的二进制文件）也会消失 ¯\_(ツ)_/¯

khellang 于 2017-05-11

对于同时寻找官方官方信息的人来说， @migueldeicaza似乎通过注册确认 .Net Standard 2 上的 ASP.NET Core 2（以及因此 NetFx）是官方计划： https ://www.theregister.co

RichiCoder1 于 2017-05-11

👍16 😄1

维护与 .NET Framework 的兼容性所涉及的妥协怎么样，这会阻碍 ASP.NET Core 还是损害其性能？

de Icaza 说，答案是使用条件代码来“创新和追求性能。在仍然瞄准共同点的同时，您可以做很多事情。你总能点亮新事物。” 这类似于在 PC 上，应用程序可以支持最新的 CPU 或 GPU 创新，同时仍然在旧硬件上运行。 “如果 CPU 有新功能，让我们使用它们，否则回退到旧代码。”

stefan2410 于 2017-05-11

为了澄清我之前的评论，因为它似乎已经丢失了，所以我提到 Angular 2 只是因为之前的评论提到了 Angular 2，而不是因为我认为这是一个很好的类比。

也就是说，与这次讨论相关的是，Angular 团队将他们从构建 AngularJS 中学到的东西应用到以 ES2016 和 TypeScript 的形式提供给他们的新技术中，并打破了旧的、缓慢的、笨重的、CPU 密集型的代码来构建一些新的东西，这对于构建丰富的浏览器和移动体验来说是指数级的。他们接受了打击，而 Angular 更适合它。

完整的 .NET 框架并不是在其上构建 Web 应用程序的最佳选择。它永远不会。它只是不适合云原生、高性能、成本敏感的分布式服务世界。这就是 .NET Core 为之构建的世界，而且它在不断变化。 ASP.NET Core 在TechEmpower 第 14 轮中从第 10 位下降到第 15 位，因为过去几个月出现了新事物。不，基准并不是一切，但它们_是_一件事，并且具有竞争力很重要。

所以，请大家，明智地使用这个暂缓执行。如果 .NET Core 2.0、NetStandard2 以及与现有 .NET 包的更高兼容性（以及希望发布更多实际的netstandard包）意味着您可以摆脱完整的 .NET 并进入 Core，那就去做吧。但是，如果您的数百万行遗留代码意味着它仍然不是一种选择，那么也许这就是上帝告诉您继续使用 ASP.NET 4.7。

markrendle 于 2017-05-11

👎12 👍4

@tbprince

如果这个帖子没有告诉你问题不在于我们是否有 UTF8 字符串，而是人们依赖这些技术谋生，老实说......

感谢您富有洞察力的帖子。特别是上面的行恕我直言，非常有见地。

FransBouma 于 2017-05-11

👍1

@willdean当 Asp.Net Core 以它为目标时，可能会期望东西会出现在适当的netstandard2x平台中。

bbarry 于 2017-05-11

@FransBouma

看起来有点讽刺。我接受。但我非常认真。

tbprince 于 2017-05-11

❤1

@stefanolson @alexwiese @yaakov-h 顺便说一句，XAML 标准 1.0 刚刚在 Build https://github.com/microsoft/xaml-standard上宣布

benaadams 于 2017-05-11

👍1

@markrendle爱你，马克，但你在这里错过了大局。 TechEmpower 基准测试在宏伟的计划中是微不足道的，我说作为一个在日常工作中花费大量时间优化 NETFX 代码的人。 ASP.NET Core 团队可能会关心它们，将其作为将其进展与其他竞争技术进行比较的一种手段，这可能会影响将净新人从 Node.JS 等其他平台吸引到 .NET Core 上，而是吸引到负责开发的开发人员。创造数千亿美元的累积商业价值，目前在 IIS 和 Windows 上运行，这只是一个不错的功能，而不是圣杯。

此外，.NET 已经是云原生的，无论这意味着什么——我已经在其上运行了大规模的分布式应用程序（每天有数以亿计的请求），而且我不需要 Docker 或 Linux 来做到这一点。这个线程上的其他人所做的规模甚至比我怀疑的还要大。这并不意味着我们不想要 .NET Core 在更好的性能（编辑：和更好的部署体验）方面提供的东西，但这确实意味着在技术上没有什么能阻止我们今天达到这样的规模。

尝试告诉 ASP.NET / NETFX 开发人员，他们构建了每天移动数亿美元的金融应用程序、为患者提供治疗的医疗保健应用程序、管理能源生产和消耗的服务，以及交通系统的实时安全监控世界扔掉他们的“遗留”代码并重新开始。这些开发人员是最初雇用 ASP.NET 团队的原因——他们购买了 MSDN 许可证、大型 Azure 企业协议、大型 Office 订阅以及为创建、开发和维护提供资金的大型 SQL Server 部署开始使用这些工具。

这些人在帖子上说的是“我绝不会为了这么少的利益而将如此巨大的变化出售给我的管理层。” 与如此突然地重新平台所需的业务活动暂停相比，每秒请求吞吐量提高 10 倍并不是一个好的权衡，尤其是在这两种技术之间存在差距的情况下。 @NickCraver在此线程上为 SO 详细说明了该问题。为了经济，平台迁移必须与业务的持续关注并行进行。这些开发人员不是 Luddites 或白痴；他们受制于支付薪水的企业的现实，使用他们的软件的客户不会容忍他们花几个月或几年的时间来重新构建他们的软件，而不会为上述企业和客户带来巨大的好处。

这里的两个阵营之间显然存在分歧：那些想要一个不受 .NET 过去限制的未开发的未来的人，以及希望能够拥有它但认识到目前对他们来说在经济上不可行的人。后者已经赢得了争论，这是理所当然的，因为他们是构成 .NET 平台最大消费者的用户。能够负担得起快速采用新技术的独立运营商的人们将与我们陷入同一条船上，但这是他们为换取免费版本的 Visual Studio、代码、来自 MSFT 的优秀 OSS 工具等而付出的代价人。

企业 / NETFX 用户以更好的基准测试的名义向某种技术纯度低头是一个不可行的要求。最好让 MSFT 勇敢地去做，让 NETFX 与 NET Core 并行更好，因为这是客户在这个线程中的要求。

.NET 是一个大帐篷，我很佩服微软在 .NET Core 和 .NET Standard 方面所做的努力，这种努力应该得到社区的赞扬和支持。但话虽如此，将 NETFX（及其用户） 15 多年的采用视为某种不便的遗产，应该匆忙放弃和遗忘，充其量是充耳不闻。如果命运最终要让两个平台出现分歧，最好与这些开发人员合作提供一个干净、渐进的迁移路径。如果 ASP.NET Core / .NET Core 被标记为与 .NET 没有任何关系的完全不同的东西，那可能会是最好的，但这个钟声不能敲响，现在也没有回头路了。因此，与此同时，让我们支持微软并追究他们的责任。

Aaronontheweb 于 2017-05-11

👍42 ❤21

@markrendle

完整的 .NET 框架并不是在其上构建 Web 应用程序的最佳选择。它永远不会。它只是不适合云原生、高性能、成本敏感的分布式服务世界。这就是 .NET Core 为之构建的世界，而且它在不断变化。 ASP.NET Core 在 TechEmpower 第 14 轮中从第 10 位下降到第 15 位，因为过去几个月出现了新事物。不，基准并不是一切，但它们是一回事，具有竞争力很重要。

所以，请大家，明智地使用这个暂缓执行。如果 .NET Core 2.0、NetStandard2 以及与现有 .NET 包的更高兼容性（以及希望发布更多实际的 netstandard 包）意味着您可以摆脱完整的 .NET 并进入 Core，那就去做吧。但是，如果您的数百万行遗留代码意味着它仍然不是一种选择，那么也许这就是上帝告诉您继续使用 ASP.NET 4.7。

请尽量避免麻木不仁并指导他人他们应该将未来的努力投入到哪里，你不知道有多少时间、精力、投入和生计处于危险之中，每个人都比你更了解他们自己的用例以及他们应该在哪里投入他们未来的努力，并将在路线图变得更加清晰时根据他们自己的个人用例做出自己的明智决定。

ASP.NET 团队的官方发言人将在他们准备就绪时发布他们自己的官方公告和承诺，在我们更清楚地了解他们选择的平台的未来方向后，每个人都可以自己决定他们应该做什么喜欢。

看着一个单一的基准，你已经中毒，并认为这是破坏信任、制造不确定性、放弃大部分现有用户群以及 15 年明智的语言和平台演变的某种理由。这可能需要更长的时间，可能需要不同的架构，但仍然可以在保持兼容性的同时实现性能。在牺牲其他一切的同时获得最大性能并不是一切，大多数最快的框架都是未知的，前三个框架是用 C/C++ 编写的，如果你想要尽可能快的性能，请在 C/C++ 上建立你的帝国 - .NET Core 将永远不会到达头把交椅。仍然建议在反向代理后面运行 Kestrel，这将掩盖任何微不足道的改进，因此关键在于尽快获得吹牛的权利。我们都想要更快的性能，但我们都想要创造价值并提供解决方案——平台是一个推动者，就像大多数框架一样，它们是达到目的的一种手段，以促进创建倍增的增值解决方案，而这些解决方案的价值大大超过了平台本身。

前进的最佳途径是接受 ASP.NET 团队为我们准备的任何计划，并尽自己的一份力量帮助推动平台向前发展，保留对任何人都没有任何好处的东西。

mythz 于 2017-05-11

👍16 😕1

我对此有很多担忧，尤其是当我的应用程序依赖于 Active Directory 时。我不知道当前是否存在或将来是否有用于 Active Directory 访问的 .NET Core 解决方案。

Cowlephant 于 2017-05-11

@twilliamsgsnetx Active Directory 即将推出。前 100 条评论中有一些不错的帖子。

hallatore 于 2017-05-11

@hallatore是的，我只是在阅读 Scott 的帖子。好东西……对于微软来说，追求不能为微软产品提供解决方案的东西没有多大意义。呵呵。

谢谢！ :+1:

Cowlephant 于 2017-05-11

@hallatore您知道最近发布的预览版中是否提供 Active Directory 支持？或者它仍然计划在夏天的某个时候？我有一个需要 AD 集成的新建项目，我真的很想使用 Core。

adam3039 于 2017-05-11

@adam3039 ，如果您位于 .NET Framework 之上，则当前可以将 AD 与 Core 1.x 一起使用。 System.DirectoryServices 似乎稍后会出现在下一个 .NET Core 2.x 预览版中？

snickler 于 2017-05-11

@snickler谢谢你的澄清！在 .NET Framework 之上创建新的 Core 应用程序时，我只看到了 Azure AD 身份验证选项。我会进一步调查！

adam3039 于 2017-05-11

基准测试的重点不是原始速度，而是在相同硬件上提供更好性能和可扩展性的能力。这意味着使用更少的硬件提供与当前性能相当的性能，这与提供业务价值直接相关。这意味着您可以在当前硬件设置或云承诺的十分之一上运行您的系统。最重要的是，由于 .NET Core 支持现代模式和实践，开发人员可以更有效地工作、更快地迭代和创新，推动为他们的业务提供更多更好的解决方案。

我还坚信，对于这里存在问题的大多数系统，应该鼓励适当地计划迁移到可靠的、健壮的面向服务或微服务架构，一次只迁移一大块单体。很高兴有一条路径可以做到这一点，您几乎可以将一些文件或代码行复制并粘贴到新项目中。您过去必须重写从 COBOL 到 4GL 或其他任何东西的所有内容，这就是为什么仍然有如此多的 COBOL 运行世界的原因。

如果最坏的情况是您真的被困在完整的 Windows ASP.NET 和 IIS 上，那远不是可能发生的最糟糕的事情。你仍然会得到所有即将到来的很酷的 C# 东西，而这些进入 .NET Core 的东西最终会得到你，只是需要更长的时间。

markrendle 于 2017-05-11

👍2

@mythz我很确定我建议人们应该做的正是你说他们应该做的。

markrendle 于 2017-05-11

@markrendle

基准测试的重点不是原始速度，而是在相同硬件上提供更好性能和可扩展性的能力。这意味着使用更少的硬件提供与当前性能相当的性能，这与提供业务价值直接相关。这意味着您可以在当前硬件设置或云承诺的十分之一上运行您的系统。最重要的是，由于 .NET Core 支持现代模式和实践，开发人员可以更有效地工作、更快地迭代和创新，推动为他们的业务提供更多更好的解决方案。

这些是关注性能的原因，.NET Core 已经做到并且已经提供了出色的性能，我不确定您从哪里获得 10 倍的利用率，因为这会使 .NET Core 比最快的 C 快 4.2 倍可用的框架和增加收入数字不会产生太大影响，因为这些数字一旦被用于服务实际工作负载就会被边缘化。我同意交付业务价值很重要，对于无法迁移到 .NET Core 和 .NET Core 无法从较小的生态系统、知识库、不确定性、不稳定性、较差的组织中获得更快的性能数字并不重要兼容性等

最有价值的互联网资产是用不使用最快框架的动态语言构建的，更重要的是一个丰富、充满活力、高效和稳定的生态系统。对他们来说，可扩展性比原始性能更重要，即使是最慢的框架也可以通过良好的缓存策略变得更快，这也比原始性能更重要。

我还坚信，对于这里存在问题的大多数系统，应该鼓励适当地计划迁移到可靠的、健壮的面向服务或微服务架构，一次只迁移一大块单体。

所以以前最大性能是最重要的，现在建议重构工作系统以引入更多网络跃点？微服务架构不是可以神奇地使所有用例中的所有系统变得更好的仙尘技术， @NickCraver已经解释了为什么它对 StackOverflow 没有意义，它对Basecamp和许多其他杰出的行业领导者也没有意义建议先使用单体，或者通过模块化系统，您可以通过更少的权衡获得更多收益。 In 在新建项目中更有意义，因为在大多数情况下，重构和重写工作系统是一个大罪，即资源使用不当，没有提供任何客户价值。

@mythz我很确定我建议人们应该做的正是你说他们应该做的。

它不是，你知道的。

mythz 于 2017-05-12

👍3

仅供参考 .NET Standard 2.0 和 .NET Core 2.0 已在https://channel9.msdn.com上实时解决 - 从11:54:00开始。还有视频的直接链接。

看起来所有的担忧都得到了官方的缓解：

斯科特·亨特：

计划是我们将在预览版 2 中让 ASP.NET Core 2.0 在 .NET Framework 上运行

Github 对什么是 .NET 没有权威性，博客（.NET 博客或 ASP.NET 博客）是团队实际发送消息到我们正在使用该工具做什么的地方，我们将在哪里移动该工具等等。

WinForms、WPF 这些是 Windows 功能，.NET Core 旨在成为 .NET 的跨平台风格，因此我们不会将仅限 Windows 的主义转移到 .NET Core 中……我想告诉客户的。 NET Framework 不会去任何地方，我们将永远支持 .NET Framework，因此您不必觉得必须将所有旧代码移至 .NET Core。迁移到 .NET Core 的原因是因为您想要跨平台或者想要完全并行

.NET Core 可以比 .NET Framework 移动得更快，因为它不是 Windows 的一部分，也不支持并行处理，因此目标并不是说每个人都必须将他们的应用程序完全从 .NET Framework 迁移到 .NET核心，如果您正在运行 WinForms 或 WPF 或 WCF，这些都是在 .NET Framework 上运行的出色工作负载，我们将永远支持这些东西。不要觉得你必须移动，你应该移动，因为你想要跨平台或者你想要完整的并排。

mythz 于 2017-05-12

👍10

他们刚刚在上面的第 9 频道直播中回答了这个问题：

ASP.NET Core 2.0 既可以使用 netstandard2.0 程序集，也可以在任何兼容 netstandard2.0 的平台上运行。
ASP.NET Core 2.0 可以在 .NET Framework 上运行。

尽管其他 MS 开发人员在此线程中发表了上述声明，但这听起来很确定。

yaakov-h 于 2017-05-12

👍17 🎉11 😄1

大家讨论得很好。

我的 2 美分是 ASP.NET Core 是微软最大的图书馆，它促进了开发人员对 .NET Core 的使用。

由于他们大量创建 .NET Standard 以支持兼容性，以及在不同风格的 .NET 中使用库，他们应该只针对 asp.net 核心中的 NETSTANDARD2.0，这样我们就可以在任何地方使用它，这有多酷在 Xamarin 应用程序或 WPF 应用程序中使用它来支持嵌入式 Web 服务器方案。这就是为什么 ASP.NET Core 从头开始如此解耦（如托管、服务器等）..

他们正在寻找的情况是，由于 .NET Core 可以在任何地方运行，因此无需支持其他风格的 .NET，只需继续使用新的快速变化的东西来支持 ASP.NET Core 未来苛刻的 API 要求并与 ASP 绑定.NET Core 与 .NET Core。

我不确切知道他们想要在 .NET Core 中使用什么超高级 API 来保持 ASP.NET Core 的增长，但可能那是另一回事了。关键是，ASP.NET Core 只是另一个库，它必须保持这种状态。

完整的 .NET Framework 仍然是成熟的，经过实战考验。许多企业客户（包括我自己）都在使用它，并希望继续在 .NET Framework 上使用 ASP.NET Core。

谢谢

joshua-mng 于 2017-05-12

FYI .NET Standard 2.0 和 .NET Core 2.0 已在https://channel9.msdn.com上实时解决......看起来所有问题都已正式缓解

知道 MS 内部的政治通常是残酷的，我想视频中相当可疑的修正主义是为了避免公开将早期的贡献者扔到公共汽车下面。我从不倾向于为公司的不诚实行为鼓掌，但也许在这种情况下，这实际上是为了更大的利益。

借用一个较早的模因，“前进，大洋洲！”

willdean 于 2017-05-12

@markrendle

如果最坏的情况是您真的被困在完整的 Windows ASP.NET 和 IIS 上，那远不是可能发生的最糟糕的事情。你仍然会得到所有即将到来的很酷的 C# 东西，而这些进入 .NET Core 的东西最终会得到你，只是需要更长的时间。<

这确实是该线程的主要观点之一。如果 asp.net core 可以在 .net 框架上运行，即使需要六个月到一年的时间才能赶上，我们大多数人都会非常满意。但是我得到的印象是，asp团队想要完全分离并且永远不会回到能够在.net框架上运行。正是未来计划缺乏明确性，使得我们这些对客户负责制定长期发展和管理计划的人非常困难。

stefanolson 于 2017-05-12

👍4

@mythz是的。

前进的最佳途径是接受 ASP.NET 团队为我们准备的任何计划，并尽自己的一份力量帮助推动平台向前发展

markrendle 于 2017-05-12

@stefanolson你误解了我，我显然不够清楚。如果出于某种原因，在 .NET Core 上运行的 ASP.NET Core 永远无法运行您的代码（例如 C++/CLI），并且您无法重写代码或重构架构，那么请继续使用 Classic ASP .NET MVC/WebAPI 或 WebForms。

（顺便说一句，我注意到我们终于从 WebForms 混乱中继续前进了。那些人刚刚开始使用它。）

markrendle 于 2017-05-12

@markrendle这显然不是所指的

mythz 于 2017-05-12

@markrendle WebForms 到 MVC 完全不同。它所做的只是改变 UI 层。我仍然可以使用相同的后端代码来生成文档等等。所以我完全没有问题。这里讨论的是完全破坏与我所有代码的兼容性，而不仅仅是我的 UI 代码。事实上，UI 代码可能是其中最便携的部分。

stefanolson 于 2017-05-12

👍7

@stefanolson也许对您和您的代码来说，从 WebForms 到 MVC 的过渡很容易，但对于很多人来说，这就像现在完全的 .NET 到 Core 一样难以克服。我的观点仍然存在：如果您无法将代码迁移到 ASP.NET Core，那就不要迁移。

markrendle 于 2017-05-12

👍2

@stefanolson @markrendle 现在在 WebForms -> MVC5 转换的中间，这对于 MVC/MVC2 来说是无法克服的，在 MVC5 中则更少。我们可能处于类似的情况，因为 ASP .NET Core 3 或更高版本可能更容易过渡。

然而，任何喝了 WebForms coolaid HARD 的人在过渡期间基本上都被搞砸了。我们得救了，因为我们没有在 ViewState 的泥潭中走得更远。我认为对于框架 -> 核心过渡来说，重要的是要有一个可靠、清晰、记录在案的过渡计划。

围绕这一点出现的不确定性是问题所在，如果在可预见的未来编写到 .NET 标准的代码将是可移植的，并且不会浪费精力，将帮助旧项目通过在 . NET Standard 并将库迁移到它。

如果该目标可能会发生变化，那并不是很好，这意味着您所做的任何事情都可能成为项目棺材中的钉子，或者您将在 ~Python 2.x~ .NET Framework 4.x 上停留很长时间。

Reanmachine 于 2017-05-12

就像范式的任何变化一样，没有使用正确范式的人正在
很难过。

我已经警告过很多人不要使用 HttpContext.Current... 然而...
今天还在写。这些应用程序将很难迁移，因为
根据上下文值，他们将拥有大量代码。

我们在使用 WebForms coolaid 时遇到了同样的问题。事件、更新面板、
等等......你仍然可以使用 ASMX 来使用 jQuery 进行 AJAX。这更难，但
这是做到这一点的“正确”方式。从这些类型的应用程序中交换是
当 MVC 出现时更容易。

现在同样的事情正在发生。模式正在改变，什么是
被认为是“良好做法”的做法也得到了发展。所有代码都写在
旧的方式（反对谷物）必须在之前完全重新考虑
向前进。

除了知道什么是我认为没有简单的过渡计划
“反对谷物”以及如何解决它。我不包括非移植 API
当然有。这完全是另一个问题。

2017 年 5 月 12 日星期五下午 3:29 Aren Blondahl [email protected]
写道：

@stefanolson https://github.com/stefanolson @markrendle
https://github.com/markrendle在 WebForms -> MVC5 中间
现在的过渡，这对于 MVC/MVC2 来说是无法克服的，在 MVC5 中则更少。
我们可能会遇到类似的情况，即 ASP .NET Core 3 或更高版本可能会
更容易的过渡。
然而，任何喝了 WebForms coolaid HARD 的人基本上都被搞砸了
在过渡期间。我们得救了，因为我们没有走下坡路
ViewState 的泥潭。我认为对框架很重要 -> 核心
过渡是有一个可靠的、清晰的、记录在案的过渡计划。
围绕这个问题出现的不确定性就是问题所在，如果它是
明确区分在可预见的未来编写到 .NET 的代码
标准将是可移植的，而不是浪费精力将帮助旧项目
通过在 .NET Standard 中编写新代码和
将库移动到它。
如果该目标可能会发生变化，那就不好了，这意味着什么
你可能会成为项目棺材上的钉子，或者你会被困在 Python 上
2.x .NET Framework 4.x 很久了。
—
你收到这个是因为你被提到了。
直接回复此邮件，在 GitHub 上查看
https://github.com/aspnet/Home/issues/2022#issuecomment-301165679或静音
线程
https://github.com/notifications/unsubscribe-auth/AAMx6CoEdzs_Ys5a8W7Ri7lwfBqcIGUdks5r5LMIgaJpZM4NReOn
.

MaximRouiller 于 2017-05-12

👍2 👎1

哇，这个帖子真是一场过山车之旅。

微软正在听 github 上的 .net 社区，这让我松了一口气
我很惊讶也很高兴这次讨论虽然充满激情，但几乎完全是专业的
我想我终于明白 .net 标准应该是什么意思了（！！）

factormystic 于 2017-05-13

🎉9

编辑：删除了关于实际上不是问题的东西的咆哮。最后阅读到帖子的结尾 - 视频消除了所有担忧。

poter134 于 2017-05-14

@poter134 嗯。你读过线程吗？好的我明白了; 它很长，但仍然......一切都已解决。这是一场不幸。 ASP.NET Core 的下一个预览版（和最终版本）将支持 .NET Standard，这再次意味着 .NET Framework。

@PinpointTownes也许你应该关闭这个问题并添加一个通知（在顶部）有一个结论？

khellang 于 2017-05-14

👍7

我什至建议锁定和限制合作者。我想一切都已经说了。

dasMulli 于 2017-05-14

👍4

道歉 - 刚开始看视频！那是一种解脱。也许顶部的摘要最适合像我这样阅读 75% 并感到绝望的人。

poter134 于 2017-05-14

👍1

也许链接到他们提到此问题的构建视频并澄清https://channel9.msdn.com/Events/Build/2017/C9L18

benaadams 于 2017-05-14

@PinpointTownes也许你应该关闭这个问题并添加一个通知（在顶部）有一个结论？

完成：+1：

kevinchalet 于 2017-05-14

@PinpointTownes ，我们社区也应该清理我们的沟通，这并不容易。在 GitHub 上发布问题、评论等的速度如此之高，以至于较小的 aspnet 团队很难处理和跟踪所有内容。我们和 .net 核心背后的人之间的这种数量不对称在 asp.net 社区站立中得到了很好的体现，这几乎完全是从他们到我们的单向流动。也许我们可以考虑在一些社区成员和 .Net 团队之间加入一个额外的层，在 Skype 会议或站立会议上转发建议等。我认为这很难实现，但也许是一个需要考虑的方向，因为社区很大。

Ponant 于 2017-05-14

👍1

@ponant ：这相当于我们之前的情况，即您向某人报告并希望该人将其传递。不，社区应该能够按原样发布他们的问题，然后团队可以选择他们想要继续处理的问题。如果这是很多工作，他们（而不是社区）应该确保他们能够处理它，例如通过研究使用比 github 问题更好的工具（因为它并不理想：一系列问题是如何工作或为什么事情不't work 与一组错误报告混合在一起），为自己添加一个层，以清除问题与他们必须解决的问题。恕我直言，这是最透明的，因为社区可以看到哪些问题被拾取并就其他人的问题提供反馈。如果它被传递给一个黑匣子，我们无法控制它，恕我直言，这是一个很大的倒退。

FransBouma 于 2017-05-14

👍4

不要忘记，您还可以进行 PR、贡献和错误修复。清楚地知道现在在哪里可以找到 repos 😉

benaadams 于 2017-05-14

👍2 ❤1

@FransBouma ，关于透明度，我同意你的看法，我承认添加一层通常是个坏主意。但是我们需要了解团队，如果他们被来自外部的信息所淹没，因为我们不能将信息转储到 GitHub，然后在他们采取不同的方向时抱怨。一个比 GitHub 更好的工具会受到欢迎，它可以与它一起工作，并且比用户的声音更现代。

Ponant 于 2017-05-14

为什么你们MS家伙从来没有吸取教训？打破一切的更新将扼杀 .NET Core 的声誉和市场，就像 WP 7.x 到 8 中发生的情况一样。

从 ASP.NET 4 迁移到 ASP.NET Core 是一个艰难而长期痛苦的过程，请不要让它变得更难。

oldrev 于 2017-05-15

👍2

他们购买 MSDN 许可证、大型 Azure 企业协议、大型 Office 订阅以及大型 SQL Server 部署，这些都为这些工具的创建、开发和维护提供资金

所以这就像头等舱乘客阻碍了经济舱的改进。好的。

markrendle 于 2017-05-15

😄3 ❤1

@markrendle微软目前每周的收入超过 20 亿美元。他们有能力更好地管理他们的工程项目。

每个工作日花费 4 亿美元，我期望的不仅仅是让整个 .NET 团队使用传说中的蹩脚 NuGet 来从比利时的过载服务器中提取日常构建，该服务器外包给一家名为 Tech Tomato 的公司。目前需要 200MB 的元数据来安装 78k 的 DLL。 https://github.com/NuGet/Home/issues/4448

也许这就是微软选择使用 GitHub 的方式，但最终用户的沟通很糟糕，团队之间的沟通变成了一场在获得足够社区关注之前过早关闭错误报告和拆分问题的竞赛。

但是，如果 Microsoft 将忽略最重要的 UserVoice 请求，并且所有看起来并不有趣的工作都被标记为“积压”，那么公开做事有什么意义呢？是的，你很忙，我们明白。你之前很忙。现在你很忙，还忙于与公共社区大队打交道。

就像 1990 年代任何运行不佳的网络论坛一样，压力过大的管理员的反应是可以预见的。评论神秘地从旧线程中消失。高级管理层承诺平息社区的愤怒，但没有兑现：

https://github.com/dotnet/cli/issues/5328
https://github.com/dotnet/corefx/issues/17522

一些微软员工已经接受了 GitHub，许多人认为所需的时间无法管理，其他人则变成了 GitHub 上瘾者，他们除了发布民意调查和推广他们的 Twitter 帐户之外什么都不做，询问“社区”如何最好地命名工厂方法或提供罗技鼠标滚轮好评如潮。

所以我通过给内部联系人发电子邮件来解决问题，就像我从 1992 年以来所做的那样。第一个回复不可避免地提到了这个 GitHub 的东西是如何完全脱离正轨的。

为不相信我关于鼠标滚轮的@PureKrome编辑。

Mouse Wheels is the new Mouse Balls

顺便说一句，当汉塞尔曼出现在这个帖子中为这个决定辩护时，我知道它会被推翻。如果你想知道微软在做什么，只需阅读他的博客，然后等待六个月，让技术朝着完全相反的方向发展。

chadwackerman 于 2017-05-15

👎10 😕6 👍6 🎉3 😄1

仅供参考：有关 2.0.0-preview2 和 .NET Framework 的一些信息； https://github.com/aspnet/Announcements/issues/243

khellang 于 2017-05-16

@chadwackerman 实际上，我认为他们不会将全部 20 亿美元用于开发 .NET。其中一些可能用于愚蠢但必不可少的东西，例如卫生纸、含咖啡因的饮料和 Azure 数据中心。

markrendle 于 2017-05-16

😄4 👍2

@oldrev

为什么你们MS家伙从来没有吸取教训？打破一切的更新将扼杀 .NET Core 的声誉和市场，就像 WP 7.x 到 8 中发生的情况一样。

也许他们做到了。否则会有更多的重大变化。

从 ASP.NET 4 迁移到 ASP.NET Core 是一个艰难而长期痛苦的过程，请不要让它变得更难。

我完全同意进展是艰难的、痛苦的并且需要一段时间，我相信 MS 的人也意识到了这一点（他们是否会让进展更容易是另一回事）

退后一步，我的团队确实评估了从 ASP.net 切换到 ASP.NET 核心以外的其他东西的可能性，但这个决定是显而易见的，因为我们对 MS 技术有很多依赖。归根结底，我们必须接受现实。

AlperenSarac 于 2017-05-17

MS 试图重复自己的错误并在Microsoft.Data.Sqlite存储库https://github.com/aspnet/Microsoft.Data.Sqlite/pull/370中放弃对完整 .NET 的支持

没有与社区进行任何讨论，也没有任何公告。

alexvaluyskiy 于 2017-05-18

👎1

@alexvaluyskiy不知道你在说什么。他们将net451替换为netstandard2.0 ，因此他们不会放弃对 .NET 的支持。 .NET 4.6.1 支持netstandard2.0 。

MartinJohns 于 2017-05-18

👍5

@MartinJohns TFS 的每一次变化都是一个重大的突破性变化，我认为应该首先宣布和讨论。
MS 仍然支持.NET 4.5.2 ，并且Microsoft.Data.Sqlite可以在它之上运行。为什么 MS 放弃对它的支持并强制用户更新到net4.6.1或netstandard2.0 ？

alexvaluyskiy 于 2017-05-18

👍1

因为更新 .NET 版本是合理的期望。这降低了维护成本，因为它们只需要支持 .NET Standard 2.0，而不是多个目标运行时。并不是他们放弃了 .NET——他们仍然支持它，而只是一个更新的版本。

MartinJohns 于 2017-05-18

👍5

您是在暗示微软必须支持所有低至 .NET 1.0 的软件包吗？

在某些版本中，东西必须收敛到 netstandard

irwiss 于 2017-05-18

@irwiss该评论并没有真正的帮助。他在任何地方都没有暗示应该支持低至 .NET 1.0 的包。但他确实提到了“仍然支持”，这是对的。截至 2017 年 5 月 3 日，.NET 4.5.2 仍然是官方支持的版本，没有计划的生命周期结束 (https://support.microsoft.com/en-us/help/17455/lifecycle-faq-net-framework)。

支持受支持的 .NET 版本并非遥不可及的要求。

MartinJohns 于 2017-05-18

👍1

@MartinJohns说实话，双方都没有太大帮助-与 sqlite 问题的最初链接是基于一个错误的前提，并试图用额外的挖掘不是一个好主意。

willdean 于 2017-05-18

👍2

我真的不知道发生了什么。为什么有很多 dotnet 这个和那个。这真是太疯狂了。我们如何对此进行跟踪？

没有关于从一个迁移到另一个的适当文档。

smithaitufe 于 2017-06-13

👎1

首先，我们有 DLL-hell，现在我们有 Package-hell……更多的事情发生了变化……；）

GiorgioG 于 2017-06-13

👍1

有什么办法可以锁定这个线程？这看起来像是属于聊天格式而不是 GitHub 问题。

MaximRouiller 于 2017-06-13

👍5

@MaximRouiller如果只有你知道我从昨天开始经历的地狱只是为了从 netcoreapp1.1 升级到 netcoreapp2.0。

如果您知道可以使我更轻松的链接，请向我推荐。

谢谢

smithaitufe 于 2017-06-13

👍1

@smithaitufe

https://weblog.west-wind.com/posts/2017/May/15/Upgrading-to-NET-Core-20-Preview

MaximRouiller 于 2017-06-13

@smithaitufe这有点离题了。而是打开一个新问题。

Rutix 于 2017-06-13

👍2

@PinpointTownes @Eilon

有什么办法可以锁定这个线程？每个评论某事的人都会发送 100 多封电子邮件来通知新活动，而他们可能属于新线程。

MaximRouiller 于 2017-06-13

👍2

@MaximRouiller我已经经历过，但没有帮助。

例如，你在那个博客上读过这个吗？

*
总体而言，除了一些重大更改之外，此框架更新提供了相对平滑的升级路径。

但是一件非常令人沮丧的事情是 SDK、运行时、工具以及它们所包含的所有不同版本的激增。尤其是当这些事情最终没有完全对齐时，因为它们都处于不同的预览阶段。
*
我决定创建一个新项目只是因为我无法让它工作。

smithaitufe 于 2017-06-13

@Rutix谢谢。我会想办法

smithaitufe 于 2017-06-13

根据此处的一些讨论，鉴于此问题已在即将发布的 Preview 2 版本中修复，我将锁定此问题。有关 ASP.NET Core 更改或问题的任何其他问题，请在相应的存储库中提交新问题。如果您不确定在哪里提交，请在 Home repo 中记录问题并标记我 (@Eilon)，我会帮助您找到正确的位置。

谢谢！

Eilon 于 2017-06-14

Aspnetcore: 新的 ASP.NET Core 2.0 包不能再在 .NET 桌面上使用

最有用的评论

所有761条评论

NTLM/AD

系统绘图

VSIX

加密货币

甲骨文ADO.NET

WPF 互操作

TL;博士;

使用 ASP.NET 为您的应用程序托管 REST API

视觉工作室支持

*请记住，在 .NET Core 2.0 上运行的 ASP.NET Core 2.0 不需要 _publish_ NETStandard 包就可以 _consume_ 它们。

下一步

预览 1 期

预览 1 期

相关问题