Aspnetcore: 讨论：ASP.NET Core 3.0将仅在.NET Core上运行

我认为现在从整体上讲很有道理。 到现在为止，.NET Core和ASP.NET Core都已经存在了很长的时间，人们已经或仍然有机会切换到它，而不会引起大的问题（与过去2.0首次取消支持的时间相比） 。

但是，尽管对于ASP.NET Core的某些组件（目前可以作为独立的依赖项存在）的含义，我感到遗憾。 因为这可能意味着各个组件将放弃对netstandard的支持，而是需要netcoreapp3.0。 特别是对于＃3756，这些组件在ASP.NET Core上下文之外将无法使用。

例如，像RazorLight这样的项目将实际上被迫放弃.NET Framework，更重要的是放弃.NET Standard支持。

这将使许多已经转而使用其组织中新的ASP.NET Core编程模型的人，在不到3年的时间里，在不受支持的平台上呆在一个受支持且积极开发的平台上。 NET Core 2.1 LTS）。

我不确定您使用了哪些分析方法来证明这一举措的合理性，但是对于在.NET Framework上运行ServiceStack ASP.NET Core应用程序，我们看到了最受欢迎的Web-corefx模板，用于在.NET Framework上运行ASP.NET Core项目。 .NET框架是超过1/3（33.8％）的份额则在同一空网页模板，是基于.NET的核心运行我们最流行的项目模板。

IMO 3年时间不足以放弃已经开始或已经迁移到新ASP.NET编程模型（以摆脱停滞的ASP.NET Framework平台）的客户，而现在他们发现已经出售的平台他们的组织搬到已经被遗弃了。

无论出于何种原因，有些客户由于仅依赖.NET Framework依赖项而无法迁移到.NET Core，如果MS不想在将来的IMO中维护ASP.NET Core 3.0中对.NET Framework的支持，则应该扩展支持.NET Framework上的ASP.NET Core 2.1的使用期限延长到7年。 自从开始使用.NET Core以来，现有生产系统的迁移可能需要花费数年的时间，很明显，ASP.NET Framework已停滞不前，官方立场是ASP.NET Core是.NET的未来编程模型，现在，相同的客户将很快就会发现，他们迁移到的新编程模型将在几年内不受支持。 容纳这些现有.NET客户的最佳方法是在一个额外的LTS期间内支持.NET 2.1，至少要提供安全补丁（理想情况下还可以解决错误）。

“杀死.NET Framework”，第2集：相同的故事，相同的角色：rofl：

可悲的是，这仅凸显了一件事：您完全无法使.NET Standard成为.NET生态系统的领先者。 它的移动速度不尽如人意，无非是最低的公分母，它总是在所有平台都包括（或将要包括）新API的最后时刻进行更新。

也许那只是我，但我从来不明白为什么它的移动速度不及netcoreapp （按定义，这是第一个获得新API的）。

您是NuGet软件包的作者，希望他们使用最新的东西吗？ 以最新的netstandard版本为目标：最初，肯定只有基于netcoreapp的应用程序能够使用它们，但最终其他平台（例如Xamarin，Mono或.NET Framework）将迎头赶上这样人们就可以使用您的软件包，而无需您进行任何更改。 事情就是这样。

当然，非.NET Core平台（如.NET Framework）可能要花一些时间才能赶上发布，因为这些发行版较为稀少且稳定性更高，但是即使需要6、12甚至18个月，我也不会认为这是一个问题，因为这是人们使用.NET Framework时想要的：一个稳定的框架，而不是一个快速发展的目标。

恕我直言，这将是使ASP.NET Core 3.0以新的netstandard TFM

我敢肯定，人们宁愿等待几个月才能将他们的.NET Framework应用程序移动到最新的ASP.NET Core版本，而不是永远被永久支持三年以上的旧版本所阻止。

做到您所承诺的：使.NET Framework成为一个稳定的框架，对于那些在迁移到ASP.NET Core时信任您的人来说，它的发展速度较慢，而不是死胡同。

我不喜欢这样在.net核心开始时，Microsoft并不是选择mono或.net framework作为跨平台，并且您说那里有多个.net运行时，所以您设计了.netstandard ，现在还有许多不支持.net核心的nuget包（出于合理的理由）。如果asp.net核心仅在.net核心上运行，许多开发者会放弃原来的asp.net核心编程模型。 那么.net standard将仅以名称存在（至少对于asp.net核心，人们开始构建netcoreapp only包）。
也许有一天，.net核心可以取代window上的.net框架，但是mono以及其他依赖于mono（xamarin，unity3d）的平台呢。
有时我更喜欢.net框架的另一个原因是.net核心共享框架确实很大，如果将您的应用程序从.net核心2.0升级到最新的.net核心2.1，您的C:/program file/dotnet文件夹有多大？ 我的文件夹中有GBs文件，并且在更新.net core运行时时会增加。 但是.net框架将仅替换旧版本。

做到您所承诺的：使.NET Framework成为一个稳定的框架，对于那些在迁移到ASP.NET Core时信任您的人来说，它的发展速度较慢，而不是死胡同。

FWIW这将是最佳策略，我的建议是扩展LTS是为现有的客户提供更多时间的最小标准，这些客户已经积极地进行市场营销以迁移到ASP.NET Core，而这些客户现在被抛弃在将来不受此支持的平台上公告。

那么.net标准是个玩笑吗？ 希望mono团队可以派生aspnetcore仓库并重命名为aspnetmono，否则我可能会离开.net堆栈。

我想这意味着在我的工作中我们将永远不会使用ASP.NET Core。 我们将永远停留在ASP.NET上，不必介意将应用程序移植到Core，因为这将涉及更多更改。

当然，如果您的目标是保持不变，那么您可以永远做同样的事情。 在我工作的地方，几年前我们开始使用ASP.NET Core，最初在.NET Framework上运行。 随着时间的推移，随着.NET Core平台的成熟和功能的增加，我们将项目切换到了netcoreapp。 一个或两个较旧的项目仍在使用ASP.NET，并且我们没有计划重写它们-它是有效的代码。 但是对于较新的内容，我们期待使用Span等功能。

可以推迟进行更改，但这不是您可以避免或应该永远避免的事情-技术是不断变化的，而开发人员的工作将始终需要学习新事物。 如果您今天在.NET Framework上使用ASP.NET Core，那么将它迁移到.NET Core的工作不太可能花费三年的时间。

来到.NET Core，这是温暖的水...

出于任何原因，有些客户由于仅依赖.NET Framework依赖项而无法迁移到.NET Core。

更严重的是，从.NET Standard 2.0开始，您适用于.NET Core的COM互操作以及WinForms和WPF等其他应用程序模型。

任何阻止ASP.NET Core应用程序从.NET Framework迁移到.NET Core的阻止dotnet / corefx中提出。

对于Xamarin； 我可能是错的，但是我认为您不太可能会用它在iOS或Android上运行网络服务器。

对于Mono客户端应用程序，当UI在Mono中运行时，Web服务器可能会运行中断并在.NET Core上运行。 尽管BSD风格目前与.NET Core差距很大，但Kestrel从未能够在Big Endian平台上运行，该平台削减了Mono的其他平台。

为了团结； 游戏会做各种奇怪的事情，所以也许这是一个未涵盖的场景； 如果游戏使用客户端中的Web服务器； 而不是在服务器上或不在proc之外； .NET Core何时可以运行该部分。

在ASP.NET Core应用程序模型之外； 例如，对于库.NET Standard更重要，因为ASP.NET Core具有各种有用的功能，Razor是一个特殊的示例。

并非所有库都只迁移到.NET Core（例如， Microsoft.Extensions.*保持.NET Standard），并且提供可能会受到@daveaglick在https：//中影响的特定方案可能会有所帮助。 github.com/aspnet/AspNetCore/issues/3757#issuecomment -434140416，因此可以将它们考虑在内； 关于哪些特定的库和/或功能可以在.NET Standard上保持可用，而不仅仅是模糊的“一切”。

ASP.NET Core在.NET Core中推动了许多更改和新的api，我可以理解使用这些功能的愿望（因为那是它们的用例之一）； 否则，它有点自欺欺人。

另一方面，如果它们也处于.NET Standard版本中，那将是很好的选择，这样其他运行时环境在实现时就可以支持ASP.NET Core 3.0。 实际上，这不会很快出现（因为.NET Standard 2.1尚未最终定稿，它需要是一个超出该版本的版本）。

也许当事情赶上来时，ASP.NET Core应用程序模型将在以后恢复到.NET Standard吗？ 尽管对于当前可用的.NET Standard进程，它可能总是运行得太快？

@gulbanana如果您的.net框架上的asp.net核心使用com怎么办？ 还是有一个仅支持.net框架的nuget包？

我认为这绝不是决定是否进行转移的问题，而只是何时。
上次这引起了“讨论”，该生态系统还没有准备好移植现有的应用程序。
现在有Windows兼容性软件包，并且.NET Core中将包含WinForms和WPF。

我认为针对.NET Framework的2.1程序包提供了一条良好的迁移路径：在netfx上迁移到2.1，然后再迁移到.NET Core。

这类似于AngularJS vs Angular：在最新的1. *版本中将现有代码迁移到组件（硬），然后移动到最新的Angular版本。 这是超级难但可行的。

通过在CoreCLR和Mono中添加令人兴奋的新功能（例如，默认接口方法或快速跨度）s）永远不会进入.NET Framework，在某个时候将.NET Framework抛在后面似乎是合理的。
这并不一定意味着“不支持” .NET Framework，而只是保持原样。

仍然有一些网站使用经典的ASP（不是ASP.NET，而是真正的旧东西）。 它仍然可以在Windows中运行并提供，只是您不会使用它创建新的应用程序。
我相信在<10年内，.NET Framework可能会出现这种情况。

我确实同意所要求的对2.1的扩展支持，但是我希望团队监视2.1软件包的下载，以便在2-3年内做出决定，以便他们需要稍微支持（修复重要的安全问题）。更长一点。

.NET Core 3.0将支持@ John0King COM。

另外：我们确实有使用.NET Remoting之类的旧应用程序。
但是这些已经是遗产。

世界基本上是在旧代码上运行的，并将继续这样做。 是否将某些东西移植到“受支持的”甚至是“新的”事物上是一个商业决定，但是在那之前，如@dylanbeattie所说：

是的，值得一提的是，是否“支持”某项功能并没有那么重要-老应用实际上不必仅仅因为可用就可以移植到新框架。 尽管由于安全威胁，Web服务器还是有些特殊情况。 对LTS的长期安全补丁支持将帮助人们。

@gulbanana它只是在将应用程序从System.Web移植到ASP.NET Core方面添加了更高的限制，因为您需要更改Web框架，基础应用程序框架，然后升级或换掉所有不兼容的依赖项（这可能涉及购买新的依赖项）。许可证）。

如果您要进行成本/收益分析，我不确定这是否会受益于ASP.NET Core。

当您基于项目开发软件时，这尤其适用，当然，每个项目的预算都足够紧张，因此，尽管可以进行定期维护，但是很难证明在没有明显的明显利益的情况下换掉整个框架是合理的。

如果您要进行成本/收益分析，我不确定这是否会受益于ASP.NET Core。

所以..很好..离开吗？ 如果您不需要迁移到ASP.NET Core，则不要这样做。
不想听起来有些讽刺，但是如果没有业务需要将应用程序保留在“最新事物”上，则不要移植它。 好处是仍然支持.NET Framework / ASP.NET classic，并且您的应用程序将按原样运行。

我同意，迁移通常是不必要的-从ASP.NET到ASP.NET Core是一个很大的变化，其中一部分变化是Core的迁移速度更快（3.0和2.0也会在api方面造成重大变化）。 本次讨论的问题是关于NETFX到corefx变化，虽然和大多数ASP.NET应用程序的核心，是不是一个大的变化了，

这似乎删除了“ .NET Framework上的ASP.NET Core”中间点，该中间点将使迁移更加逐步和容易。 此后，迁移ASP.NET MVC / WebAPI / etc。 向ASP.NET Core的应用将是一个巨大的变化，它将同时更改Web框架和基础运行时。

对于大型企业应用程序，我希望这会很痛苦。 我的团队一直在密切关注这一点，但是一两年来，但是：

• EntityFrameworkCore不能满足我们的所有要求，直到现在，.NET Core 3.0才将EntityFramework本身引入.NET Core。 我不相信已经明确传达了其中的多少以及它将在什么平台上运行，我可能需要实际测试预览版本才能看到。

• 就大规模应用而言，OData的故事似乎仍然悬而未决。 从OData 3 / System.Data.Services到OData 4 / WebAPI以及更高版本，需要（大量）工作。 这是几年来尚未解决的事情，老实说，我不确定是否会解决。

另外，现在我们不得不削减所有其他不受支持的技术（AppDomain，Remoting等），而不是能够并行或在以后的阶段中进行这项工作。

此外，现在我们必须首先裁剪所有其他不受支持的技术（AppDomains，Remoting等），而不是能够并行或在以后进行此工作。

为什么不能先迁移到2.1？

@davidfowl除非我们在3.0 / 3.1 / etc中遇到一些新功能，否则我们可以将其用作中介。 我们需要进行迁移。 我还没有做完整的分析，到目前为止，我们大多数都被EF和OData屏蔽了。

需要迁移ASP.NET Core 2.1中的新功能吗？ 我的意思是.NET Framework上的ASP.NET Core 2.1。

几年前，当这个问题浮出水面时，我记得曾抱怨说，移植所有内容太难了。 这是我当时做出的旧github评论的引文：

想象使用Active Directory或Office COM自动化的Web应用程序，或使用基于System.Drawing的某些库做缩略图的Web应用程序，或与WPF应用程序共享代码

很棒的事情是，从.NET Core 3.0开始，所有这些情况都受支持。 为了简化它，已经进行了大量的工作。

@davidfowl我也是。

假设我们在ASP.NET/MVC/WebAPI中可能使用了某些功能，但该功能未在2.1中实现，但确实在更高版本中提供。 在这种情况下，2.1将不是可行的垫脚石。

不过，我必须进行更彻底的分析，以查看是否确实存在我们需要的2.1中没有的关键要求。

@PinpointTownes

可悲的是，这仅凸显了一件事：您完全无法使.NET Standard成为.NET生态系统的领先者。 它的移动速度不尽如人意，无非是最低的公分母，它总是在所有平台都包括（或将要包括）新API的最后时刻进行更新。

您没有错，但是您对.NET Standard的目标一无所知。 该标准的目标从来不是驱动创新，而是驱动融合。 如果从这个角度来研究它，那是设计上必须落后的事情，因为我们必须考虑哪些概念可以是通用的，甚至应该是通用的。 如果您想知道这是什么样子，请邀请我看看所有.NET实施所有者审查后，过去三周我合并的35个以上PR。

我们将.NET Core视为创新的最前沿平台。 我们已经建立了一些功能，使我们能够处理随之而来的客户流失和风险，这比.NET Framework更好。 但是，并非所有对.NET生态系统重要的功能都是.NET Core经验的一部分。 例如，提前编译在Xamarin和Unity上更为突出。 当我们采用.NET Core功能并将其添加到标准中时，我们需要考虑其运行时环境，操作系统和硬件限制。

也许那只是我，但我从来不明白为什么它的移动速度不及netcoreapp （按定义，这是第一个获得新API的）。

现实情况是，“快速移动和破坏性事物”并不是我们整个观众都欣赏的东西。 如果必须在.NET Core的主要版本中删除API，这已经很糟糕了，但实际上与.NET Standard无关。 因此，我们必须稍微慢一些，并且只包含我们认为足够成熟的概念即可添加。

做到您所承诺的：使.NET Framework成为一个稳定的框架，对于那些在迁移到ASP.NET Core时信任您的人来说，它的发展速度较慢，而不是死胡同。

但这仍然假设.NET Framework最终将获得.NET Core具有的所有功能，但会出现时间延迟。 我们了解到这根本不现实。 我们可以决定不对.NET Core进行大刀阔斧的创新，也可以接受工程学上的现实，即很多新功能永远都不会使它回到.NET Framework中。 我们相信，我们将为客户提供最好的服务，以保留.NET Framework的核心价值支柱（一个成熟且丰富的开发平台），同时还允许客户利用.NET Core的新功能。 展望未来，我希望我们将更愿意在需要运行时，库和语言更改的领域进行创新，就像我们为Span<T> 。 这些东西虽然很昂贵，但它们也使我们能够改变人们编写代码的方式。 一个很好的例子是接口的默认实现，编写涉及算术的通用代码的能力，能够使用硬件内在函数等。这些功能可能正是由于风险而我们不打算移植到.NET Framework的那种功能。 。

我认为让我们的Web堆栈能够利用这些功能是很有意义的。 唯一的方法就是消除ASP.NET Core也可以在.NET Framework上运行的限制。 请记住，使ASP.NET Core在.NET Framework上运行的最初原因是因为.NET Core根本没有足够的API。 在.NET Core 3.0上，我们将有超过12万个现有API 。 这是整个.NET Framework的一半以上，甚至包括WinForms和WPF。 是的，仍然缺少大量的API，但是我们已经取得了长足的进步。 尽管我们永远不会实现100％的均等，但我希望我们根据客户数据进一步缩小这一差距。

@ yaakov-h如果真是如此，我会感到惊讶。 当您进行分析时，请告诉我。

您没有错，但是您对.NET Standard的目标一无所知。 该标准的目标从来不是驱动创新，而是驱动融合。

而且您正朝着相反的方向前进：放弃ASP.NET Core的.NET Standard，因为它的移动速度不够快，迫使面向ASP.NET Core的NuGet包也放弃了它。 不要让我认为它是融合的，我不是那么无知：rofl：

如果从这个角度来研究它，那是设计上必须落后的事情，因为我们必须考虑哪些概念可以是通用的，甚至应该是通用的。

这是一个选择，而不是技术问题：没有什么可以阻止您在检查是否将给定API包括在corefx / coreclr中时是否将其包含在.NET Standard的新版本中。

如果您想知道这是什么样子，请邀请我看看所有.NET实施所有者审查后，过去三周我合并的35个以上PR。

我并不是说这是一个简单的任务，它证明了我的观点：您正在等待太多时间来创建新的netstandard版本，而您很少这样做，这是一个痛苦的过程，因为它伴随着大量的同时使用新的API。

现实情况是，“快速移动和破坏性事物”并不是我们整个观众都欣赏的东西。

但这正是每次ASP.NET Core迭代工作的方式：它带有（有时是巨大的）重大更改，这些更改使编写为某个版本的软件包与下一个版本不兼容。 但是，您没有给我们太多选择：永远更新或保留旧版本，其支持策略与我们过去所拥有的不相关（不仅仅是ASP.NET/.NET，Windows的生命周期也很大）这些天较短）。

展望未来，我希望我们将更愿意在需要运行时，库和语言更改的领域进行创新，就像我们对Span所做的那样。 这些东西虽然很昂贵，但它们也使我们能够改变人们编写代码的方式。 一个很好的例子是接口的默认实现，编写涉及算术的通用代码的能力，能够使用硬件内在函数等。这些功能可能正是由于风险而我们不打算移植到.NET Framework的那种功能。 。

是什么使您无法引入包含那些“风险”更改的新的并行.NET Framework版本（例如.NET Framework 5）？ 同样，这不是技术问题。

是否有机会在Microsoft.AspNetCore.Razor之外推广Microsoft.AspNetCore.Razor.Language和Microsoft.AspNetCore.Razor aspnet或将其保持在netstandard浪潮中？ 即使razor仅用于html，也有一些库将其用于邮件模板，如果我们可以继续使用它，那将是很棒的。

此举表明，.NET路线图中缺乏对netstandard的支持，这与之前所说的相反。 如果主要的新图书馆之一放弃了netstandard，那么采用它就不是一个好兆头。

现在，.NET开发人员应该对微软公开开发的所有其他新库有所期待吗？ 社区能否获得有关netstandard的未来及其采用的更正式的声明？

@terrajobst我完全理解您的观点，即关于不向.netstandard添加那些似乎尚未准备好跨所有平台的API（并且可能永远不会）。 但是，这并没有阻止您（MS）引入netstandard2.0，例如，当UWP尚未准备好支持它时。 据我了解，稍后花费了相当大的精力来添加该支持，但是您做到了。 那是一个不同的故事吗？

而且您正朝着相反的方向前进：放弃ASP.NET Core的.NET Standard，因为它的移动速度不够快。

ASP.NET Core仅在.NET Framework和.NET Core上有意义，但是.NET标准必须由所有人实施。 例如，使Xamarin / Unity提供主要由服务器Web堆栈使用的API根本就没有意义。

这是一个选择，而不是技术问题：没有什么可以阻止您在检查是否将给定API包括在corefx / coreclr中时是否将其包含在.NET Standard的新版本中。

这就是我们在.NET Core v1天中所做的。 我们已经将标准与.NET Core与v2分离。 是的，这是一个选择，但不是一个任意选择。 目标是能够使用.NET Core更快地移动。 与在单个其他运行时相比，考虑功能如何在其他N个运行时的上下文中花费的时间更多。

这是一个痛苦的过程，因为它同时带有大量的新API。

不，这是一个痛苦的过程，因为您必须使用多个实施者和多个不同的运行时来审查设计。 但是，事实上，聚合和捆绑比在进行过程中进行协调要便宜得多。 CoreFx存储库是一个高容量的存储库。 对于Xamarin和Unity而言，与捆绑在一起的功能进行审核要比从费劲喝水并订阅有关CoreFx的所有API讨论容易得多。

但这正是每次ASP.NET Core迭代工作的方式：它带有（有时是巨大的）重大更改，这些更改使编写为某个版本的软件包与下一个版本不兼容。

而且因为您不喜欢这样，您想通过使.NET Standard与.NET Core相匹配来将其强加给所有人吗？ 抱歉，这个说法对我来说毫无意义。

是什么使您无法引入包含那些“风险”更改的新的并行.NET Framework版本（例如.NET Framework 5）？ 同样，这不是技术问题。

是什么让您认为这不是技术问题？ 并行发布.NET Framework版本不是可行的解决方案。 首先，由于它是一个OS组件，因此需要维修，因此相当昂贵。 您不知道.NET Framework 3.5和4.x的分支/服务/修补策略有多复杂。 添加第三个几乎是不切实际的。 其次，这样做还存在风险，因为我们需要对激活进行更改才能为COM激活的托管组件等选择正确的运行时。 这就引出了一个问题，即我们是否也同时支持进程内和有多少组合。 这不是一个简单的任务，也不是没有风险。

不要让我认为这是融合

@PinpointTownes这是收敛...在.NET Core上

例如，使Xamarin / Unity提供主要由服务器Web堆栈使用的API根本就没有意义。

有些人不仅想在.NET Core上而且要在UWP上使用ASP.NET Core，所以为什么不同时在Xamarin上使用呢？ https://aspnet.uservoice.com/forums/41199-general-asp-net/suggestions/32626766-support-for-asp-net-core-running-on-uwp-as-windows

对于您而言，毫无意义的事物与您不想支持的事物之间存在差异。

CoreFx存储库是一个高容量的存储库。 对于Xamarin和Unity而言，与捆绑在一起的功能进行审核要比从费劲喝水并订阅有关CoreFx的所有API讨论容易得多。

我是否建议过这种极端的方法？ 我确信您会找到一个折衷方案，例如，一旦尘埃落定，在.NET Core中引入新标准API不久（即几周）之后再进行讨论。

而且因为您不喜欢这样，您想通过使.NET Standard与.NET Core相匹配来将其强加给所有人吗？ 抱歉，这个说法对我来说毫无意义。

您以为我不喜欢这样，但是您错了：我喜欢快速发展的东西-即使作为60个NuGet软件包的维护者，有时也很痛苦。 我不喜欢的是强迫每个人以相同的速度移动，在路中间放弃人们，因为他们无法跟上。

我不确定如何使.NET Standard像.NET Core一样快地移动是一种惩罚：没有什么可以迫使您瞄准最新的netstandard TFM。 仅在需要最新的API集时才这样做。 如果您不需要它，请以较旧的版本为目标，以便您的软件包可用于更广泛的平台。

从一般开发人员的角度来看，这是一个总的胜利：您可以使用最新的.NET Core运行时可以使用的最新闪亮的API编写程序包。 当其他平台赶上来时，您的软件包也可以在那里使用：您无需使用多目标软件包或重新发布软件包。

首先，由于它是一个OS组件，因此需要维修，因此相当昂贵。 您不知道.NET Framework 3.5和4.x的分支/服务/修补策略有多复杂。 添加第三个几乎是不切实际的。

我当然可以想象这对您来说并不理想，就像删除对ASP.NET Core 3.0的.NET Framework支持对于无法迁移到.NET Core的人们来说不是理想选择。 但是，我认为您-Microsoft-拥有比普通公司迁移到.NET Core还要多的资源来处理这个问题，这完全是错误的吗？ （我什至没有在谈论您不拥有和控制的外部依赖项）。

其次，这样做还存在风险，因为我们需要对激活进行更改才能为COM激活的托管组件等选择正确的运行时。 这就引出了一个问题，即我们是否也同时支持进程内和有多少组合。 这不是一个简单的任务，也不是没有风险。

当然，这并不容易。 而且有风险。 但这就是主要版本所表明的：有可能发生故障的风险。 现在，在被迫永远停留在ASP.NET Core 2.2上以及冒着风险转移到.NET Framework 5以使用ASP.NET Core 3.0的风险之间，您认为人们会选择什么？

但是，我认为您-Microsoft-拥有比普通公司迁移到.NET Core还要多的资源来处理这个问题，这完全是错误的吗？

根据我的经验，人们总是高估我们拥有的资源以及仅为了维持现状而必须要做的工作。

但是在这种情况下，这甚至不是资源问题。 我们可能只是开源了.NET Framework，然后所有PR都将直接转到.NET Framework。 它与机器的复杂性和兼容性风险有关。 它是一个集中化的框架，甚至并行发布也共享一组公共资源，例如激活。 我们一次又一次地被证明是错误的，我们只能分配聪明的人，让他们正确地出来。

现在，在被迫永远停留在ASP.NET Core 2.2上以及冒着风险转移到.NET Framework 5以使用ASP.NET Core 3.0的风险之间，您认为人们会选择什么？

我认为，与尝试将.NET Core功能反向移植到.NET Framework相比，在.NET Core上扩展受支持的API的范围更为实用，以使更多的人可以平稳地迁移到.NET Core。 我们在那里所能做的就是令人悲伤的事。 请记住，并行发行版还带来其他挑战，例如让IT允许您安装它，将其链接到安装程序中或等待主机为您提供机器等。

这是否适用于ASP.NET Core的所有部分，还是将某些有用的，可普遍重用的部分（例如Microsoft.AspNetCore.Http.Extensions ）保留在.NET Standard中？

@andriysavin

@terrajobst我完全理解您的观点，即关于不向.netstandard添加那些似乎尚未准备好跨所有平台的API（并且可能永远不会）。 但是，这并没有阻止您（MS）引入netstandard2.0，例如，当UWP尚未准备好支持它时。 据我了解，稍后花费了相当大的精力来添加该支持，但是您做到了。 那是一个不同的故事吗？

是。 .NET Standard 2.0具有零个全新的API。 它被定义为.NET Framework和Xamarin的交集。 无论是什么增量，我们都只需要它即可与现有代码达到合理的兼容性。 唯一的工作是在UWP和.NET Core中。 这些代码库最初被设计为.NET的现代重置，但据我们了解，该重置是不可行的。 由于要添加的API /技术已经很成熟并且在受限环境（Xamarin iOS）中受支持，因此复杂性很低-只是大量的移植工作。

但是现在我们正在谈论添加全新的功能和概念，这是另一种驱动力。

根据我的经验，人们总是高估我们拥有的资源以及仅为了维持现状而必须要做的工作。

以我的经验，Microsofties一直高估了我们拥有的资源和要做的工作量，以仅支持现状。 您的论点确实在两个方向都有效：sweat_smile：

我认为，与尝试将.NET Core功能反向移植到.NET Framework相比，在.NET Core上扩展受支持的API的范围更为实用，以使更多的人可以平稳地迁移到.NET Core。

让我们清楚一点：我全力以赴，但是直到.NET Core赶上来并实现.NET Framework具有的大多数/所有功能时，它才起作用。 在此之前，您仍然会看到人们被缺少的功能或缺少的API所阻止。 遗漏的东西太多了，以为大型传统的单片应用程序可以迁移到.NET Core而不会遇到问题，这是不合理的。

我绝对理解您的担忧。 但是最终，使您的生活更轻松的事情有可能使我们的生活更加痛苦：不支持.NET Framework对我们来说将是PITA。

我绝对理解您的担忧。 但是最终，使您的生活更轻松的事情有可能使我们的生活更加痛苦：不支持.NET Framework对我们来说将是PITA。

我理解的那部分。 但是，替代方案不会是.NET Framework中的更多功能，而只是功能不那么强大的ASP.NET Core。

在过去的几年中，我们试图共同发展.NET Framework和.NET Core。 并不是说我们在努力避免工作。 我个人花费了不菲的时间与我们的运行时工程师进行交流，以解决例如绑定重定向的噩梦。 或4.6.1中损坏的.NET Standard 2.0支持。 我们尝试了。 这不是意志力的问题，而是实用性的问题。

在.NET Core赶上并实现.NET Framework具有的大多数/所有功能之前，它不起作用

以我的经验，某些API的可用性甚至不相关。 在企业环境中，至关重要的是支持和部署的复杂性。 与“ .NET Core LTS发行版及其目前涉及的灵活部署所提供的三年支持相比， 稳定的工具，我可以自信地说，它仍将是一年后的现状。 我们对每个版本进行了更改，谁知道3.0的新框架引用是否是正确的解决方案。 因此，在与企业打交道时，这绝对是一个巨大的痛点，在这种情况下，您不能只是更新事物或以应有的方式进行更新； 通常，他们希望以过去5年以上的方式来完成此任务。 它们被框架宠坏了，任何令他们感到不舒服

但是，替代方案不会是.NET Framework中的更多功能，而只是功能不那么强大的ASP.NET Core。

这几乎是我去年建议的：ASP.NET Core程序包仍可在.NET Framework上运行（例如，通过定位netstandard20和netcoreapp30 ），但提供的功能集更为有限，而功能却少得多有趣的表现。 有时人们想要的是有效的东西。 不是新的闪亮事物。 不是超级快的东西。

在过去的几年中，我们试图共同发展.NET Framework和.NET Core。 并不是说我们在努力避免工作。 我个人花费了不菲的时间与我们的运行时工程师进行交流，以解决例如绑定重定向的噩梦。 或4.6.1中损坏的.NET Standard 2.0支持。 我们尝试了。 这不是意志力的问题，而是实用性的问题。

显然，我们并没有就所有事情达成共识，但是不用说，你们的所作所为给我留下了深刻的印象（是的，即使像HttpClient那样的事情都很难应付）。

我真的很抱歉成为那个人：sweat_smile：

到目前为止，在ASP.NET Core方面，我已经看到Razor作为一种具体的东西出现了，人们通常希望在ASP.NET Core之外使用它们。 我认为这是合理的，我们应该确定更多类似的领域（这将是更有用的讨论）。 ASP.NET Core 2.1和2.2仍将支持.NET Framework，但我认为永远不支持.NET Framework是不合理的。

@terrajobst

一个很好的例子是接口的默认实现，...这些功能可能正是由于风险而我们不打算移植到.NET Framework的那种功能。

有了这个声明，DIM就死了。 重点在于遗产的演变。 如果它不适用于旧版，甚至无法应用于尝试将旧版与新版架起的图书馆，那么它对任何人都无济于事。

到目前为止，在ASP.NET Core方面，我已经看到Razor作为一种具体的东西出现了，人们通常希望在ASP.NET Core之外使用它们。

您可以将Microsoft.Owin.Security.Interop backcompat'程序包，ASP.NET Core数据保护和基础依赖项添加到列表中。

这几乎是我去年建议的：ASP.NET Core程序包仍可在.NET Framework上运行（例如，通过定位netstandard20和netcoreapp30 ），但提供的功能集更为有限，而功能却少得多有趣的表现。 有时人们想要的是有效的东西。 不是新的闪亮事物。 不是超级快的东西。

我们也对此进行了讨论。 面临的挑战是，我们不能完全封装它们，因为某些基础平台API和功能将必须渗入公共API。 这意味着集成到ASP.NET Core中间件中的库还必须提供多种实现。 但更糟糕的是，如果不创建分裂，甚至可能无法实现，因为公共交换类型可能是仅核心的，这将创建两个不再兼容的ASP.NET Core版本。

@HaloFour

有了这个声明，DIM就死了。 遗产演变的整个要点。 如果它不适用于旧版，甚至无法应用于尝试将旧版与新版架起的图书馆，那么它对任何人都无济于事。

我认为您是将旧代码与现有安装进行合并。 即使我们要将DIM移植到.NET Framework，也必须升级到新版本才能使用该功能。 虽然这可能是仅.NET Core的功能，但它仍然使我们能够开发.NET Core，同时仍然能够使用针对.NET Framework编译的代码。

@terrajobst您不断提到Unity。 他们有自己的CLR实现吗？ 我给他们留下了印象，他们正在使用Mono。

Unity具有多种.NET实现，包括其自己的非单AOT版本IL2CPP。 他们的类库和受支持的API也与标准Mono不同。

@terrajobst

我认为您是将遗留代码与现有安装进行合并。

仍然在积极维护和开发“遗留”应用程序时并没有太大区别。 升级框架与必须迁移到.NET Core之间存在巨大差异。

虽然这可能是仅.NET Core的功能，但它仍然使我们能够开发.NET Core，同时仍然能够使用针对.NET Framework编译的代码。

为了什么目的 .NET Core中的那些“演进的” API都不适用于.NET Standard。 考虑到它将如何在他们自己的API中产生不兼容的差异，没有库编写者会碰它。

我同意@HaloFour。 唯一能够使用DIM的人是那些只针对.NET Core的库作者，因此基本上就是corefx和aspnetcore。 我无法想象会有其他人靠近它。

唯一能够使用DIM的人是那些只针对.NET Core的库作者，因此基本上就是corefx和aspnetcore。

好吧，另一种措辞方式是，当您可以在.NET Core，Xamarin，Mono和Unity上运行时，唯一无法使用的平台将是.NET Framework。

我无法想象会有其他人靠近它。

我会想象这样的功能在库中将具有曲棍球棒采用模式，这是有道理的。 最后，库作者将始终考虑覆盖率与功能集。 对于应用程序，决定起来更加容易，因为您知道（并且经常控制）您的目标环境。

@ yaakov-h

这是否适用于ASP.NET Core的所有部分...

关于什么软件包发生什么的暂定列表在这里： https :

@terrajobst我认为默认接口实现将成为C＃的语言功能。 说.NET Framework不支持它，您实际上是在说.Net Framework将永远卡在C＃7.3版或至多下一个版本中。 这种差异并不是任何人都希望在生态系统中发生的。

我们运行一些.NET Core工作负载，但也运行多年的.NET FX项目。

安全地升级到.NET Core（甚至是从.NET Framework开始）是一项非常大的任务。

Microsoft是否有计划发布一些工具来帮助将项目从至少.NET FX上的ASP.NET“升级”到ASP.NET Core到.NET FX？

MSDN上有关于创建新的VS项目以及导入视图和重新调整项目的文章，但是有很多遗留的东西（全局asax，路由等），我希望有一个中心位置来记录旧的和新的帮助方式移植一切。

是什么使您无法引入包含那些“风险”更改的新的并行.NET Framework版本（例如.NET Framework 5）？

到那时，如果不是.NET Core 3.0，是否有任何优势？ 它已经并排并且具有“风险”更改。 然后，.NET Core的下一组功能是否需要.NET Framework 6等？

使用.NET Core 2.0中已经存在的api和.NET Core 3.0中的新功能集，.NET Core不能使用Framework 4.x作为极其长的LTS版本来实现“ .NET Framework 5”吗？

凭空猜测； 在这一点上，要弥补.NET Core 3.0与.NET Framework 4.x的任何特定差距，而不是将.NET Framework更改为.NET Core，这将是一个较小的工程挑战。

实用建议：ASP.NET Core 2.2是否有可能在LTS的支持期限超过普通3年的情况下成为LTS？

我确信这将满足那些现在必须坚持使用完整框架的人们，同时还给予他们（1）足够的时间实际迁移到.NET Core，以及（2）足够的动机从ASP.NET MVC迁移到ASP .NET Core（当他们无法移动到.NET Core _yet_时）。

我仍然不太清楚，.NET Framework上的ASP.NET Core是遵循.NET Core 2.1 LTS还是遵循.NET Framework v4.6.1 +支持周期（即，因为它在.NET FX上运行），因此在可预见的将来得到支持吗？

@mythz ASP.NET Core在.NET Core支持生命周期内涵盖了，无论您在什么平台上运行它。

我认为，最好的做法是实际上至少对3.0、4.0和5.0进行.net标准的更新，并进行实际沟通，以便在某个时候将.net框架完全迁移到.net核心。
其他一切都还没完成。

你们今天有客户在为LTS支持付费吗？ （只是一个探索性问题）。 多少时间就足够了？

@terrajobst听起来真正的问题是netstandard是整体的。 听起来我们不需要netstandard而是版本化的API集。 这些也将是TFM，例如base2.0 + span将是两个API集。

然后，您可以基于API集发展标准，并且可能仅在完整框架中实现一些API集。 （这也将使其他平台更容易实现netstandard，因为可以省略某些API集）。

有了API集之后，将为支持程度较低的目标（如完整框架）创建一个单独的ASP.NET Core构建。

@Sebazzz这是一个非常奇怪的话题。 我们不能通过重新设计netstandard来破坏该线程吗？ 您可以为此在dotnet / standard上提出问题，但我会告诉您这个想法已经提出并被拒绝。

@davidfowl我不认为这完全是“奇怪”或“失败”。 如果说比他提出的方式要少一些的话，这听起来正是我们所需要的。 如果所有这些的问题是我们最终不得不将所有这些Web服务器内容塞进Xamarin和Unity这样的无关的实现中，而这些实现都不在乎Web服务器，那么IMO将成立一个单独的“ .NET Web Server Standard” API组。将是理想的解决方案。

@Sebazzz @masonwheeler

@terrajobst听起来真正的问题是netstandard是整体的。 听起来我们不需要netstandard而是版本化的API集。 这些也将是TFM，例如base2.0 + span将是两个API集。

我们尝试了多种方式（配置文件，PCL，宽松合同，然后是版本合同集，后来成为.NET Standard 1.x）。 随着时间的推移（随着平台版本和API集的发展），很难使用工具来理解兼容性规则。 当今的.NET标准是我们迄今为止最接近可行模型的标准。 虽然并不完美，但这至少是我可以在几分钟内解释并且不会引起人们的关注的东西。

我很乐意更详细地讨论.NET Standard，但我同意@davidfowl ，它不属于此处。 如果需要，请在https://github.com/dotnet/standard中提出问题

编辑我已将.NET Standard注释标记为脱题。

@ Shayan-To

@terrajobst我认为默认接口实现将成为C＃的语言功能。 说.NET Framework不支持它，您实际上是在说.Net Framework将永远卡在C＃7.3版或至多下一个版本中。 这种差异并不是任何人都希望在生态系统中发生的。

此功能需要更改语言以及更改运行时。 它与泛型相似，因为它更改了类型系统的规则。 一般来说，C＃不知道您要编译哪个框架（它只是传递了一组描述框架提供的API的参考程序集）。 将支持所有不需要更改API的C＃功能（例如，空换行符?.或_用于丢弃表达式）。 这与当您使用最新的编译器和语言版本并针对缺​​少相应API的较旧版本的.NET Framework时，编译器始终工作的方式相同。 例如，如果您以.NET Framework 3.5或4.0为目标，那么async / await将不起作用-必须使用4.5或更高版本才能使用Task 。

伙计，我为你们感到。.完全过渡到.net核心是imo，长期而言是正确的事，我更喜欢将提供的更高创新速度。

但是，人们对此会感到不高兴。其中相当一部分是交流。 当宣布为期3年的2.1 LTS时，fullfx的人们有望能够升级到3.0并仍然运行fullfx，他们将把asp.net核心出售给其雇主和客户，使自己的声誉脱颖而出，并且现在他们会觉得地毯已经被拉出了。 他们作为长期解决方案出售的产品，即asp.net的未来，现在（在感知上）限制了3年的支持

没关系，现在更容易迁移，切换平台永远是一个风险，这将是这些人没有想到，没有计划或没有预算的风险和开发工作。

大多数开发人员都希望迁移到.net core 3，但是除了潜在的依赖关系，他们无法更改（或涉及风险更改）之外，他们现在还必须重新进行迁移并承诺这次，这将是一项长期投资。这可能很难，但是由于3年的支持周期，他们将不得不这样做。

同样，我要放弃fullfx，但是我真的认为您应该考虑将LTS扩展到支持它的最新版本。 同样非常清晰地交流，例如在博客，会议/会议等中，哪些部分仍将是netstandard以及仍在2.1 /完整框架上的人们如何仍然可以利用它们。

否则，您很有可能将叙述变成“ Microsoft再次将其专注的开发人员留在后面”。这并不是说很公平，只是试图警告您可能发生的事情。

LTS的时间合理吗？

大概6年？ 我认为消息传递将在接待中扮演重要角色。.最终，无论如何，有些人都会感到沮丧：/

@davidfowl @ aL3891

作为参考，Java LTS“高级支持”为5年，“扩展支持”（付费）为另外三年。 Java 11是LTS发行版，已于上个月发布，将分别支持到2023年9月和2026年9月

我们正在研究“扩展支持” LTS产品，当我们拥有它们时将提供更多详细信息。 这可能为需要在.NET Framework版本（2.1.x）上受支持的ASP.NET Core的客户提供比当前LTS支持期更长的选项。

也是仅供参考，我今天在ASP.NET社区站上聊了一些公告： https : & list & index

请指定目标.net标准。 asp.net核心可以将.netstandard2.1或3.0定位netcoreapp目标，并在以后让mono和.netframework进行追赶，但是如果asp.net核心的目标.netcoreapp库。

和.net core的发布速度始终快于.net framework和mono ，
如果Microsoft开始将更多框架/库定位到netcoreapp （这也会导致在nuget目标.netcoreapp上引起更多库），mono和.netframework最终将消耗.netcoreapp程序集。

如果是这样， .netstandard将变成.netcoreapp 😂

@ John0King请提供ASP.NET Core之外所需的类型示例。

1. @poke提到的剃刀
2. MVC筛选器接口/属性（我有一个帮助器类库，其中包含一些ActionFilters和TagHelpers以及用于string，int和long等的常见静态/扩展方法。我使用PrivateAssert="All"来引用MVC包，因此在使用时使用库中的其他地方，该项目不必引用MVC程序集，我想我必须将库分成两个，一个是.netstandard ，另一个是.netcoreapp ）

另一个问题是：我应该为哪种类型的类库创建一个问题？ （ .netstandard与.netcoreapp ）。 今天在asp.net core 2.1中非常简单。 选择.netstandard作为类库，选择.netcoreapp或net461作为Web项目。

如果Microsoft开始将更多框架/库定位到netcoreapp，mono和.netframework最终将消耗.netcoreapp程序集（这也会导致nuget目标.netcoreapp上出现更多库）

如果人们不努力分离.netstandard库中的内容和.netcoreapp库中的内容，就会发生这种情况

MVC筛选器接口/属性（我有一个帮助器类库，其中包含一些ActionFilters和TagHelpers以及用于string，int和long等的常见静态/扩展方法。我使用PrivateAssert =“ All”来引用MVC包，因此在使用此库时在其他地方，该项目不必引用MVC程序集，我想我必须将库分成两个，一个是.netstandard，另一个是.netcoreapp）

你能详细说明吗？ 这没有道理。 MVC是一个ASP.NET Core框架，不能单独使用。

@davidfowl这个库是一个帮助器类库，当我在asp.net核心MVC项目中工作时，可以使用那些过滤器，并且只能在控制台应用程序中使用其扩展方法。

@davidfowl这个库是一个帮助器类库，当我在asp.net核心MVC项目中工作时，可以使用那些过滤器，并且只能在控制台应用程序中使用其扩展方法。

我还是不明白您是在谈论包含MVC和其他随机事物的库吗？

不幸的是，这种事情在企业软件中很常见-“帮助程序库”，例如，该公司的MVC实用程序+该公司的WPF实用程序+该公司的Telerik实用程序...
当“ .NET”是单个统一平台时，这更有意义。

@davidfowl是的。 帮助器库中有一些类/方法，您可以在任何地方使用这些类型/方法。 当您在mvc项目中引用该库时，则可以使用其与mvc相关的类/方法。

哦，好吧，这只会迫使您的库更好地分层😉

不幸的是，这意味着任何仍在内部部署的人都不能支持其软件超过3年的时间。 例如，当您发布针对.netcore 3.0的应用程序时，您的客户已有3年的时间，然后被迫升级。 有些行业会很好，某些行业肯定不会。

这是最大的问题，我想可以使.net core对于许多人来说完全是个难题。 我实际上同意最终这是正确的方向，但是可以肯定，这将阻止很多地方使用.net核心。

真的希望.net团队对此做出回应。

事实是，ASP.NET Core是一个Web框架。 在哪个行业中运行三年完全未经修改的网站安全？ 如果不是安全漏洞，它将是浏览器弃用您依赖的内容（即TLS 1.4），或者是要求站点在其新监视表上运行的用户。

在那段时间跨度你应该能够只用少量的调整和次要依赖更新，但规划脱身不更新在所有Web应用程序的年年底是鲁莽的。

我认为，如果您只是将ASP.NET Core 2.1的LTS期限增加到5-7年，这对社区来说将是更可口的。

根据我们的经验，与“现代” Web开发相比，企业级企业开发的发展步伐缓慢，但他们仍然希望确保不会在明显较旧的平台上进行新的投资。 这些应用程序通常要花费一年甚至什至“启动”，更不用说能够在3年内进行重大突破性升级了。 这些企业（通常仅面向内部）Web应用程序通常获得7至10年的支持，尽管我认为ASP.NET Core 2.1的LTS达到10年是不合理的。 5年比3年是更好的解决方案，而7年肯定会让几乎每个人都感到舒服。

这仅是必需的，因为ASP.NET Core 3.0需要重大的重大更改才能删除.NET Framework支持。 假设重大变化不大，则将来的LTS版本不应遵循此标准。

我不确定如何使.NET Standard像.NET Core一样快地移动是一种惩罚：没有什么可以迫使您瞄准最新的netstandard TFM。 仅在需要最新的API集时才这样做。 如果您不需要它，请以较旧的版本为目标，以便您的软件包可用于更广泛的平台。

如果平台永远赶不上怎么办？ 然后，您将拥有一个以netstandard2.3目标的库，该库需要功能A，该功能仅在.NET Core和Xamarin上可用，但对于.NET Framework不可用。

然后netstandard2.4出现了，有了一些新的Apis，并且其中一些API可以移植到.NET Framework。 现在怎么办？

您如何定位需要运行在.NET Framework上的netstandad2.4中的功能的库，但是netstandard2.4无法定位.NET Framework，因为它无法实现netstandard2.2 。

然后，您必须交叉编译到三个平台：
netstandard2.2用于旧平台）和net4x用于网络标准）只是为了支持在netstandad2.4添加的功能，以及net4x can also implement but not support because of APIs that went into netstandard2.3`中添加的功能。

如何使包裹作者更轻松地编写和运送他们的金块包裹？

只有当所有平台都将支持的最低公分母流入netstandard时，整个事情才能起作用。 除非您希望更多API抛出PlatformNotSupported异常，否则它将导致netstandard内的碎片化。

我当然可以想象这对您来说并不理想，就像删除对ASP.NET Core 3.0的.NET Framework支持对于无法迁移到.NET Core的人们来说不是理想选择。 但是，我认为您-Microsoft-拥有比普通公司迁移到.NET Core还要多的资源来处理这个问题，这完全是错误的吗？ （我什至没有在谈论您不拥有和控制的外部依赖项）。

这里的实际问题是什么？ 无法从ASP.NET旧版迁移到ASP.NET Core的人将无法移动ASP.NET Core是否以.NET Framework为目标。 它们不能或不会的最可能原因是特定于System.Web库，该库在.NET Framework的ASP.NET Core上也不起作用。 现在拥有应用程序的人显然已经有了工作组。

而已经在.NET Framework上使用ASP.NET Core 2.1的人，如果它能正常工作，为什么要移动呢？ 显然，所有这些都已经存在，并且ASP.NET Core 3.0新增的其他所有功能都很不错。

至于其他：
有很多方法可以将应用程序迁移到.NET Core，例如，从旧的单片应用程序中分解出部分并将其重新实现为微服务，它们还可以降低风险并随时间分散

如果平台永远赶不上怎么办？ 然后，您将拥有一个面向netstandard2.3的库，该库需要功能A，该功能仅在.NET Core和Xamarin上可用，而.NET Framework则不可用。

如果大多数支持.NET标准的平台都不能实现API，那么很有可能它不应该成为标准的一部分，不是吗？ （实际上，很有可能相反，因为Xamarin运行的平台通常受到更多限制）。 我希望在审查包含在.NET Standard中的API时能够检测到此类问题，但我可能是错的。

而已经在.NET Framework上使用ASP.NET Core 2.1的人，如果它能正常工作，为什么要移动呢？

• 支持？ （三年期支持非常短）
• 仅在3.0中存在错误修复？ （LTS版本仅修复了严重的错误和漏洞）
• 您需要引用仅与最新的ASP.NET Core版本兼容的库吗？

有很多方法可以将应用程序迁移到.NET Core，例如，从旧的单片应用程序中分解出部分并将其重新实现为微服务，它们还可以降低风险并随时间分散

是的，当然，从理论上讲，这是解决该问题的理想方法。 但：

• 有些应用程序依赖您无法控制的外部库。 如果该库在.NET Core上不起作用，并且供应商不希望（或无法）移植它，那么您很不走运。
• 迁移到.NET Core可能既昂贵又耗时。 如果哪怕是Microsoft最好的团队也在为此而挣扎，您真的认为对于任何普通团队来说，这都那么容易吗？ 我们必须等待3.0才能看到Entity Framework 6最终与.NET Standard兼容。

不要误解我的意思：我全都为新应用程序使用.NET Core。 但是ASP.NET Core与.NET Framework兼容的事实帮助许多公司以合理的成本迁移到ASP.NET Core。 我坚信，如果没有这种“不太困难”的迁移途径，它将永远不会如此流行。

微软，要求扩展2.1支持是否过多？ 2021年对我们来说还不够长，我们没有足够的资源/时间进行转换。 至少到2022年？ 额外的一年确实会给我们带来改变的机会，尽管这是痛苦的。

请记住，我们的许多第三方供应商尚未将其库迁移到.Net Core兼容性，这是造成挂断的最大原因。

仅供参考https://github.com/aspnet/AspNetCore/issues/3753#issuecomment -434521855

我认为有必要扩展LTS的同时，也应考虑将IMO将.NET FX上的ASP.NET Core滚动到.NET FX支持周期。 对于初学者来说，在不同的支持周期上使用.NET Framework的不同部分会造成混淆，将它们组合在一起会更有意义。 其次，用于2.1的代码已经编写，发布和依赖，因此与使用.NET Core 3.0进行主动开发相比，支持2.1所需的资源要少得多。 如果同一个团队同时维护这两者，那么我还要假设，与完全不同的经典ASP.NET代码库相比，最近更熟悉的模块化ASP.NET Core活动代码库将更易于支持。

当微软在2012年宣布Silverlight 5的停产时，他们仍将支持它直到2021年10月（尽管它在2015年的Chrome浏览器和2017年的Firefox中都已弃用）。 这是针对完全被放弃的技术，在这里不是这种情况，基本上是相同的代码库，编程模型，活跃的开发团队仍在工作，只是在.NET Framework上运行现有的软件而已被放弃。

在此宣布之前，有强大的消息传递功能，MS从未放弃过.NET Framework，它非常适合仅Windows的工作负载（与用于跨平台/高性能工作负载的.NET Core相反），并且ASP.NET Core是未来将来将同时支持.NET Framework和.NET Core的编程模型，并将.NET Standard作为开发针对多个平台的库的解决方案。

现在很清楚，.NET Core是所有新项目的未来，但这是关于如何对待现有的投资和现有的客户，这些客户到目前为止已经基于此指南进行了决策。 当需要支持现有系统时，现有.NET开发团队将如何发展，他们将被迫保留在经典的ASP.NET上（他们现有的技能/知识在今天已经过时了），而上下文切换以开发新的Apps在.NET Core上。

如果我被迫在.NET Framework上维护系统，那么我宁愿在可以访问活跃的知识库/生态系统的新ASP.NET编程模型上进行开发，然后被迫恢复使用旧的ASP.NET无限期，但是除非FX上的ASP.NET Core与WebForms具有相同级别的支持，否则这是不可能的。

MS也有机会将FX上的ASP.NET Core定位为“稳定的”开发环境（即，固定在ASP.NET Core 2.1上）。 自.NET Core启动以来，在过去几年中成为.NET开发人员并不容易。 我们实际上已经不得不放弃所有尝试移植到.NET Core <1.x的努力，因为它很难跟上不断变化的潮流，直到.NET Core 2.x才能够支持它并迁移现有的应用程序。 另一方面，现有的ASP.NET Framework开发人员发现他们选择的平台停滞不前，然后被新的ASP.NET Core编程模型取代，并通过扩展侵蚀了他们现有的技能/知识。 终止对FX的ASP.NET Core的支持会终止向.NET Core的流行的分阶段迁移策略，除非他们能够将整个系统升级到.NET Core，否则它们将冒险（没有应急备用）运行在废弃的平台上。这样可以避免考虑进行迁移尝试），如果他们无法迁移日常工作的现有系统，这也将失去他们参与将来的ASP.NET Core开发模型的机会。只有它享有与WebForms相同的支持，才有可能-我希望仍在考虑之中。

没有人提到：在我们的asp.net核心应用程序中，我们需要托管WCF服务，这是从.net框架迁移的唯一痛苦点。 遗憾的是，我没有看到有关.net core 3上服务器端wcf支持的任何消息。

@DamianEdwards @davidfowl @natemcmaster我们在同一条船上。 我公司有许多产品都在.Net Full框架上的ASP.Net Core上运行，由于我们销售的行业发展缓慢，我们对这些产品的支持时间超过3年。 在我们的情况下，为.net core 2.2扩展LTS将毫无意义，因为我们必须将ASP.net核心应用程序移植回ASP.Net。 当然，这正在击败关键人物！ 您是否会建议在较短的时间内支持应用程序？ 不幸的是，这也是我们无法控制的。 我们从事的行业可能需要一年时间才能推出我们的新软件。

不幸的是，这意味着任何仍在内部部署的人都不能支持其软件超过3年的时间。 例如，当您发布针对.netcore 3.0的应用程序时，您的客户已有3年的时间，然后被迫升级。 有些行业会很好，某些行业肯定不会。

这是最大的问题，我想可以使.net core对于许多人来说完全是个难题。 我实际上同意最终这是正确的方向，但是可以肯定，这将阻止很多地方使用.net核心。

真的希望.net团队对此做出回应。

@davidfowl https://github.com/aspnet/AspNetCore/issues/3753#issuecomment -434594997

哦，好吧，这只会迫使您的库更好地分层😉

这个论点不是朝相反的方向起作用吗？

我不明白的是什么实际上阻止了您对ASP.NET Core进行适当的分层体系结构？
因此，是的，.Net Framework上某些运行时功能不可用，例如Span<T> ，但这并不意味着它根本不可用。 它是可用的，只是性能不如.Net核心。 我们可以解决。

可以针对.net核心和.net标准以一些变体形式实现一些低级别的实现。 我怀疑这样做的空间很大，因为API通常以NuGet包的形式提供。
许多库作者确实支持针对不同平台的不同实现，这一直都是。

您能否详细说明阻止您支持.Net Framework / .Net Standard的确切原因。 一些简单的示例，对于采用特定于平台的实现方式，有什么不能抽象的呢？

阻止您支持.Net Framework / .Net标准。 一些简单的示例，对于采用特定于平台的实现方式，有什么不能抽象的呢？

让我烦恼的是，需要运行时或框架更改的项目

• 内部GC指针； 因此，仅通过没有对象的ref创建安全的Span： MemoryMarshal.CreateSpan<T>(ref T reference, int length)
• Utf8String s
• 默认接口实现
• 线程池自定义工作项
• 基本类型的跨度重载：流，套接字，TextReader / TextWriter，WebSocket
• IAsyncDisposable对以下基本类型的重载：流，套接字，TextReader / TextWriter，WebSocket等。
• IAsyncEnumerator在以下基本类型上重载：流，套接字，TextReader / TextWriter，WebSocket等。

奖励项目

• 硬件内在函数（x86，x64，ARM）
• 转义分析（新分配到堆栈）
• 并行运行时版本
• 修复绑定重定向和版本控制

我不明白为什么我们不能只拥有不再支持网络框架的网络标准版本。 就像Windows Phone在1.2之外没有netstandard支持一样。 为什么我们不能将标准向前推进，而最终还是永远不会允许netcore，mono，xamarin等实现与之匹配。 然后由库制造商决定他们要实现哪个netstandard版本，以最大程度地覆盖范围。

此更改使xamarin和mono不再可以使用aspnetcore。 这使得库制造商被迫同时瞄准netcore和netstandard或更糟糕的是却放弃了netstandard，而只瞄准了netcore。

这最终将导致netstandard的死亡。

阻止您支持.Net Framework / .Net标准。 一些简单的示例，对于采用特定于平台的实现方式，有什么不能抽象的呢？

让我烦恼的是，需要运行时或框架更改的项目

• 内部GC指针； 因此，仅通过没有对象的ref创建安全的Span： MemoryMarshal.CreateSpan<T>(ref T reference, int length)
• Utf8String s
• 默认接口实现
• 线程池自定义工作项
• 基本类型的跨度重载：流，套接字，TextReader / TextWriter，WebSocket
• IAsyncDisposable对以下基本类型的重载：流，套接字，TextReader / TextWriter，WebSocket等。
• IAsyncEnumerator在以下基本类型上重载：流，套接字，TextReader / TextWriter，WebSocket等。

奖励项目

• 硬件内在函数（x86，x64，ARM）
• 转义分析（新分配到堆栈）
• 并行运行时版本
• 修复绑定重定向和版本控制

第一个列表中的项目听起来像是可以更改netstandard的候选对象？

它们中的大多数似乎无法带到其他运行时中，但是似乎没有人希望修订CLR以获得新版本以将默认接口实现引入.NET Framework。

同时，Microsoft似乎不想继续开发与.NET Framework永远不兼容的.NET Standard版本。 否则，这真的不是问题-只需使用netstandard30或netstandard40前进并放弃对Framework的支持即可； 并以.NET Core为目标的那些较新的标准之一。

我觉得这个线程等是微软有效地将自己涂在角落的结果。

同时，Microsoft似乎不想继续开发与.NET Framework永远不兼容的.NET Standard版本。

这不屑一顾； .NET Standard 2.1即将完成，它在.NET Standard 2.0之上Span重载； 这可能使其与.NET Framework不兼容。

.NET Standard仍在向前发展。

否则，这并不是真正的问题-只需推动netstandard30或netstandard40并放弃对Framework的支持即可； 并以.NET Core为目标的那些较新的标准之一。

问题在于使每个运行时都不仅仅是与新的标准之一不兼容的框架。 然后与每个标准不兼容。 .NET Standard中包含的内容需要由各种运行时达成共识才能实现。

Mono和Unity的各种GC是否会很快支持内部指针？ 如果不将它们添加到.NET Standard中，则将阻止它们从该.NET Standard中删除任何将来的.NET Standard，直到更改其GC以处理它们。 然而; 最好添加可以立即实现的api，并保存将来无法使用的api。

是否已将正确添加到Core的api永久永久修复并强制每次运行时使用？ 想要与下一个标准兼容以实施？

某些Core 2.1 API在预览1和预览2之间进行了更改（由于使用情况反馈）； 因此，在发布之前，甚至很难知道Core X中的api是什么。 然后，将其中哪些是正确的集合添加到标准中，以供所有运行时实现（或抛在后面）。

当2个浏览器必须先实现该功能才能接受标准时，.NET Standard的方法仍比浏览器标准更具攻击性。

如果一个新的.NET Standard可以与.NET Core同时发布，并且所有运行时都可以立即实现它，然后ASP.NET Core可以通过.NET Standard使用所有新的api，那将是很好的。 但是虽然理想中不错，但也不实用。 甚至还有相当多的未在.NET Core中实现的经过批准的api

基本问题是ASP.NET Core是否可以使用它所请求的api并以其附带的.NET Core版本附带（同时发布）。 还是只能使用.NET Core早期版本中附带的api-因此有机会成为该.NET Core的.NET Standard版本？ （由于它看起来像.NET Standard版本，目前在apis 1版本中落后于.NET Core；使用的样本大小为1）

如果ASP.NET Core可以使用api； 然后这些api会进行使用情况测试并评估它们是否是好的api； 如果不是，那么可以提出更好的API。 如果ASP.NET Core无法使用它们，那么当它们成为.NET Standard候选者时，它们是否是好的api仍然是未知之数。

没有人愿意为新版本修订CLR，以将默认接口实现引入.NET Framework。

通过支持传统的.NET Framework工作负载（包括WinForms和WPF），. NET Core本质上是对CLR的修订。 但是以一种更可持续的，面向未来的方式来完成？

这不屑一顾； .NET Standard 2.1即将完成，它在.NET Standard 2.0之上具有3104个新api，包括基于基本框架类型的Span重载； 这可能使其与.NET Framework不兼容。

包括.NET Framework 4.8和.NET Framework 4.9吗？

将来的Framework更新总是有可能获得这些新的API。 目前，.NET Framework永远不会获得DIM似乎是一成不变的，因此，任何具有DIM方法的接口都可以_never_移植到.NET Framework。

通过支持传统的.NET Framework工作负载（包括WinForms和WPF），. NET Core本质上是对CLR的修订。 但是以一种更可持续的，面向未来的方式来完成？

而且不是向后的。 尽管微软展示了在.NET Core上运行的Paint.Net之类的东西，但我无法在.NET Core上运行现有的服务器端项目，大多数人也不能。

如果一个新的.NET Standard可以与.NET Core同时发布，并且所有运行时都可以立即实现它，然后ASP.NET Core可以通过.NET Standard使用所有新的api，那将是很好的。 但是虽然理想中不错，但也不实用。

这也可能不切实际，但是我认为如果有两个版本的ASP.NET Core，人们总体上会更开心：

• 与.NET _Core_关联的快速移动的最新版本，可以使用它所需要的任何新API。
• 与.NET _Standard_绑定并在更多地方运行的LTS移动速度较慢； 最终赶上了较老的前沿技术，但始终落后。

通过将其绑定到.NET Core，您将不得不做出一个并非所有人都满意的折衷方案。 我得到了必须快速采取方法的理由，但是对于整个.NET生态系统也存在合理的关注。

• 与.NET Core关联的快速移动的最新版本，可以使用它所需要的任何新API。
• 与.NET Standard绑定的，运行速度较慢的LTS版本，可以在更多地方运行； 最终赶上了较老的前沿技术，但始终落后。

因此，如果ASP.NET Core 3.0仅作为.NET Core 3.0推出； 但是后来，当他们是具有API的.NET Standard时； 也发布了.NET Standard的ASP.NET Core 3.x软件包（即使ASP.NET Core已升级到4.0）； 可以满足您的要求吗？

@ yaakov-h

与.NET Standard绑定的，运行速度较慢的LTS版本，可以在更多地方运行； 最终赶上了较老的前沿技术，但始终落后。

这是什么意思？ 您始终可以将ASP.NET Core 2.1与@DamianEdwards提到的扩展支持

您可以始终将ASP.NET Core 2.1与扩展支持结合使用

请不要分裂社区！
（基于投票）您期望1/3的开发人员留在asp.net core 2.1中吗？ 还是期望2/3开发人员创建必须维护其库2版本的nuget包？

@benaadams

因此，如果ASP.NET Core 3.0仅作为.NET Core 3.0推出； 但是后来，当他们是具有API的.NET Standard时； 也发布了.NET Standard的ASP.NET Core 3.x软件包（即使ASP.NET Core已升级到4.0）； 可以满足您的要求吗？

恰恰。

@davidfowl

您始终可以将ASP.NET Core 2.1与@DamianEdwards提到的扩展支持

这里似乎有冲突的消息：

1. 保留旧版本的LTS 2.1很好
2. ASP.NET Core的发展如此之快，以至于我们甚至都无法等待.NET Core与后续.NET Standard之间的一个发布周期。

我认为（2）引起了很多混乱，并担心被抛在后面。

@ John0King

（基于投票）您期望1/3的开发人员留在asp.net core 2.1中吗？ 还是期望2/3开发人员创建必须维护其库2版本的nuget包？

我希望库作者决定他们关心的最低ASP.NET Core版本是什么，并以此为目标。 这就是他们今天已经在做的事情。 一些库支持ASP.NET Core 1.x和2.x，而某些库仅支持2.x。 没什么两样

@ yaakov-h

我不太了解冲突消息是什么。 当前的2.1是LTS，可在.NET Core和.NET Framework上运行，并且支持3年。 这不是新消息，而是我们从一开始就收到的相同消息。

ASP.NET Core的发展如此之快，以至于我们甚至都无法等待.NET Core与后续.NET Standard之间的一个发布周期。

基于此处的评论进行推测。 正式地，我们与.NET Core的交付周期联系在一起，并且我们已经在每个版本中添加和使用新的API。 在.NET Framework上运行的ASP.NET Core从来都不是永久性的东西（甚至称为ASP.NET Core），它始终是踏脚石。 我们只需要添加回足够的核心API，以便客户可以合理地编写功能齐全的应用程序。

ms小组对此有何回应？

不幸的是，这意味着任何仍在内部部署的人都不能支持其软件超过3年的时间。 例如，当您发布针对.netcore 3.0的应用程序时，您的客户已有3年的时间，然后被迫升级。 有些行业会很好，某些行业肯定不会。

这是最大的问题，我想可以使.net core对于许多人来说完全是个难题。 我实际上同意最终这是正确的方向，但是可以肯定，这将阻止很多地方使用.net核心。

真的希望.net团队对此做出回应。

不幸的是，这意味着任何仍在内部部署的人都无法支持其软件超过3年

那只是胡说八道，实际上您可以进行升级。 唯一无法使用的时间是在嵌入式环境中，但是嵌入式软件比3年的支持窗口有更多的问题。

@schmitch我不确定您的意思吗？ 显然，您可以升级，但是对于某些行业而言，升级到新版本的软件将成为一项庞大的项目，该过程可能需要数年时间，具体取决于发布周期以及这些行业的技术进步程度（或不取决于技术水平）。

@davidfowl

我的猜测是，即使支持了10年，也无法满足抱怨的人们的需求。

不确定您如何期望人们接受它，每个做出这种决定效果的人都将面对被出售以迁移到的平台，这不仅没有未来，而且他们基于最新编程模型构建的现有投资正朝着继续前进的方向发展。不到3年的不受支持的平台（截至本公告之日）。 其他曾考虑过先通过迁移到.NET Framework谨慎地分阶段迁移到.NET Core的人现在面临着没有后备情况的风险-它必须在新的.NET Core运行时或崩溃中运行。

开发者平台本身不应成为目标，因为在平台上创造的价值成倍增长，其次是平台本身的价值。 像这样的盲目行动似乎使提高平台速度的资源最大效率比在其上创建的生态系统的投资更为重要。 .NET Core 2.1位上的墨水甚至还没有干dry，但现有系统（在FX上）已经被视为一种负债（以提供最小支持为目的），而不是它们为生态系统增加的资产和价值。

如前所述，企业系统可以以轻松的步伐移动，经常同时平衡开发人员的团队，以提供持续不断的改进，员工和客户的数量需要不断提高以从中获得恒定的ROI。 许多迁移需要经过仔细的计划和严格的测试才能进行中，这可能需要数年的时间-他们宁愿花时间创造价值，然后争先恐后地摆脱获得其支持的平台。 大型的棕地系统不是像iPhone这样的商品，它可以轻易地丢弃并每隔几年进行无缝升​​级，开发中的系统越旧越长，投资的价值就越大，而从中迁移出来的难度就越大。鉴于迁移没有创造任何价值，这很难吸收，它需要资源，吸收机会成本，增加风险，并且他们所希望的最好的结果是无缺陷迁移，其现有系统的运行与以前完全相同。

不论FX支持的有效期限是什么，都会有现有的系统在运行中遇到障碍，否则将无法迁移。 那么，什么是指导？

ASP.NET Core 2.1已经开发出来，要使FX / .NET Core上运行ASP.NET Core的工作已经投入了沉没成本。 因此，应根据MS资源来制定决策，以维护一个已经开发的平台（在LTS之后）与累积的成本，恶意和惯性而放弃一个流行的平台。

我不确定我是否明白当时的要求。 自2.1推出以来，LTS的生命周期没有改变。 如果您使用LTS版本（无论是.NET Core还是.NET Framework）编写应用程序，那么距离您“不受支持”还需要3年的时间。 我不太了解地毯在支撑方面是如何从您的下方拉下的，这没有改变。 您将需要升级以获得任何平台更新。

现在我知道2.1是.NET Framework上支持的最后一个LTS版本，意味着没有升级的地方，但这就是扩展LTS支持的地方。如果应用程序在这6年后仍无法迁移到.NET Core，因为API是缺少，请提出问题，以便我们了解差距。

我不确定我是否明白当时的要求。

该线程要求MS做出不同程度的承诺，包括：继续与.NET Core一起开发，以“慢速火车”进行开发，不放弃ASP.NET Core 2.1并保持与WebForms相同的支持水平，扩展LTS 。 我的喜好是不要放弃它作为ASP.NET Core的托管选项（编辑：在上面列出的任何内容都更可取），该选项不会阻止.NET Core仅v3 +，同时为现有.NET提供大量实用程序外汇投资。

现在，我知道2.1是.NET Framework支持的最新LTS版本，这意味着没有地方可以升级到

这意味着它已成为不受支持的平台，它上的任何人都必须像对待熔岩一样对待它，并争先恐后地将其下架，直到它达到其不受支持的EOL端。

• 任何考虑将其用作升级到.NET Core的暂存平台的人都变得不太可行，因为如果迁移花费的时间比预期的长，或者面临任何依赖，他们将面临被困在不受支持的平台上的风险。他们依靠不能在.NET Core上运行。
• 任何被迫使用企业现有托管基础结构的.NET Framework服务器的人都无法参与使用新的开发人员模型和生态系统，而不得不看到其现有的经典ASP.NET知识/技能的价值每天都在降低。
• 团队无法迁移其现有.NET Framework所需的系统，因此需要将上下文切换到.NET Core上的新ASP.NET Core项目。
• 任何组织都不想被迫进行计划外的迁移，因为他们用来作为预算，计划和投资决策依据的指南已经改变。

对于未开发的项目，仍然可以或正计划迁移到.NET Core的人或不必维护旧系统的任何人来说，这也不是问题，但这确实会影响现有的.NET FX生态系统和ASP.NET Core由于不再能够考虑利用.NET FX上的流行托管选项而变得更加贫穷。

在理想的情况下，每个人都将使用.NET Core，但是由于此决定而贬值了.NET FX的大量投资。

如果由于缺少API而在这6年之后该应用程序仍无法迁移到.NET Core，

有很多人不能或不希望使用.NET Core，他们希望它共享与经典ASP.NET相同的支持水平（当前消息表明这是无限期的）。

缺少API并不是阻止迁移的唯一原因，例如，它们可能依赖于开发团队创建它不再存在的依赖关系，这是一个不可更改的关键组件，无法安全重构（例如没有测试），它与其他仅.NET FX的系统共享，由另一个没有预算，无法更改它的部门维护，或者由于外部因素（例如其企业管理的基础架构仅支持在.NET Framework服务器上运行）而维护。

感谢您使用这种决定杀死.NET Standard。

到目前为止，我们一直在忽略.NET Core，因为有很多第三方程序集还没有针对Core。

许多愿意支持Core的供应商都半心半意地这样做，例如，不具有仅在.NET Framework上可用的本机API的Managed ODP.NET。

然后您会做出这种决定。

不，我们不会更快地采用.NET Core只是因为Microsoft对.NET Framework的支持太多了，而且它无法提供你们一开始所追求的.NET Standard。

@davidfowl我可以举两个例子说明为什么很难迁移到.NET Core-WCF（许多现有的企业应用程序都在使用它，我相信其他人已经提出了这个问题），并且.NET Core / NET中缺少Adomd库标准（用于与SSAS通信，也用于企业应用程序中，在SQL https://feedback.azure.com/forums/908035-sql-server/suggestions/35508349-adomd-core中进行了跟踪）。 .net核心3兼容性包（是的！）应该修复一些其他问题（winforms）-我们必须拭目以待，看看它是如何工作的。

@mythz

该线程要求MS做出不同程度的承诺，包括：继续与.NET Core一起开发，以“慢速火车”进行开发，不放弃ASP.NET Core 2.1并保持与WebForms相同的支持水平，扩展LTS 。 我的首选是不要放弃它作为ASP.NET Core的托管选项，它不会只支持.NET Core v3 +，同时为现有的.NET FX投资提供大量实用程序。

好了，我们目前正在探索扩展LTS支持的问题，但是我们并没有考虑永远为ASP.NET Core提供一流的.NET Framework支持（这正是您所要的）。 您正在寻求与WebForms相同级别的支持的ASP.NET Core版本只能获得安全修复程序和可靠性修复程序。 我可以向您保证，随着功能出现在较新版本的ASP.NET Core中，使用ASP.NET Core 2.1的用户的满意度将下降（至少，这是我的直觉告诉我的），因为这些更改仍然会消失。达到。

缺少API并不是阻止迁移的唯一原因，例如，它们可能依赖于开发团队创建它不再存在的依赖关系，这是一个不可更改的关键组件，无法安全重构（例如没有测试），它与其他仅.NET FX的系统共享，由另一个没有预算，无法更改它的部门维护，或者由于外部因素（例如其企业管理的基础架构仅支持在.NET Framework服务器上运行）而维护。

这非常普遍（即使在Microsoft内部也是如此），这就是为什么我们在.NET Core 2.0中添加了引用.NET Framework dll的功能的原因，因为事实证明，即使大多数程序集不是为.NET Core编译的，它们也兼容。 现在有些事情将永远无法使用（例如AppDomains ...），但是我希望随着我们添加更多的API表面，不仅起作用的库集将缩小到微不足道的数目。

@pjmlp

我看不出这是如何杀死.NET Standard的。 .NET Standard比ASP.NET Core大得多。 这是关于创建可在任何支持的.NET平台上工作的可重用共享库（例如Microsoft.Extensions *）。

到目前为止，我们一直在忽略.NET Core，因为有很多第三方程序集还没有针对Core。

哪个？ 是否正在支持这些组件，或者这些程序集将永远不支持.NET Core？

许多愿意支持Core的供应商都半心半意地这样做，例如，不具有仅在.NET Framework上可用的本机API的Managed ODP.NET。

我同意这一点，并且在.NET Core上已经看到大量残缺不全的版本的库（即使Microsoft附带了一些库），但我要说的是潮流正在改变。 造成这种情况的某些原因是因为.NET Core 1.0上最初缺少一组API。 使用2.0和2.1，我们已经看到大量库可以更轻松地移植到内核/标准，而不会损失太多功能。

@voltcode感谢您的具体反馈！ 我们希望在今天（3年左右）支持.NET Core项目的时间内，其中一些类型的兼容性问题会消失或减少。

@davidfowl

....

到目前为止，我们一直在忽略.NET Core，因为有很多第三方程序集还没有针对Core。

哪个？ 是否正在支持这些组件，或者这些程序集将永远不支持.NET Core？

在我们的案例中，ODP.NET很明显，因为Oracle并未将100％的驱动程序功能移植到Core中。

许多愿意支持Core的供应商都半心半意地这样做，例如，不具有仅在.NET Framework上可用的本机API的Managed ODP.NET。

我同意这一点，并且在.NET Core上已经看到大量残缺不全的版本的库（即使Microsoft附带了一些库），但我要说的是潮流正在改变。 造成这种情况的某些原因是因为.NET Core 1.0上最初缺少一组API。 使用2.0和2.1，我们已经看到大量库可以更轻松地移植到内核/标准，而不会损失太多功能。

但这并不是我们的许多客户看到的。

只是为了让您了解这种决定如何影响.NET的未来，在最近的项目中，客户付出了开发工作，将应用程序从.NET Framework迁移到Java以进行UNIX部署，因为他不愿意这样做。押注.NET Core和残缺的ODP.NET实现，而JDBC驱动程序与.NET Framework ODP.NET驱动程序提供1：1功能奇偶校验。

其他人可能也会选择其他替代堆栈。

在您的普通企业应用程序中，有大量的依赖项将无法移植。

这个问题浮出水面。 你们（@MSFT）可能也要检查一下。 仅1小时，已有50多个评论。

@davidfowl

我看不出这是如何杀死.NET Standard的。 .NET Standard比ASP.NET Core大得多。 这是关于创建可在任何支持的.NET平台上工作的可重用共享库（例如Microsoft.Extensions *）。

我不明白，如果不是可重用的共享库，ASP.NET Core是什么？ 如果使库成为现代且快速的趋势是放弃.NET Standard支持，那么这是一个棘手的消息。 如果Newtonsoft.Json可以运行得更快，它应该只切换到.NET Core 3吗？ 应该是Autofac吗？

我确实了解造成这种情况的原因，但是我不确定自上次出现这种情况以来，论点和评估方式是否已发生很大变化！ 我想我们会拭目以待...

我将把用例放在那里，并就目前与此相关的情况给出一些看法：

就自托管（http.sys）Web API和围绕各种服务的静态Web内容而言，AspNetCore对于我们的堆栈而言非常出色。 我们来自Nancy，这很扎实，但是从我们的角度来看也存在很多缺陷，因此大约一年前我们改用了AspNetCore。 今天，我们正在2.x上运行我们的每个代码库。 在许多情况下，我们完全可以迁移到纯.NET Core目标。 但是，我们还建立了许多利用AspNetCore的服务，这些服务也依赖于System.DirectoryServices和System.Drawing 。 从这些服务的角度来看，在离开.Net Framework之前，我们将更改Web托管技术。 不幸的是，由于同时管理2种不同的Web托管技术的复杂性以及我们的团队规模，我们很可能也将AspNetCore从我们其余的服务中剔除掉，​​以期在两个目标之间实现更兼容的支持。

简而言之-这个决定将迫使我们在将来的某个时候（可能是LTS在2.x到期时）完全退出AspNetCore，这是我现在不知道的。 如果涉及到这一点，我们可能会编写自己的内部解决方案来替换AspNetCore，因为就实际使用的AspNetCore功能而言，我们的用例非常狭窄（也就是说，我们利用_d今天对我们来说是一个巨大的附加值）。

其他人可能也会选择其他替代堆栈。

这是公平的，但是替代堆栈具有相同的支持策略。 Java已移至类似的LTS模型（https://www.oracle.com/technetwork/java/javase/eol-135779.html）。

在您的普通企业应用程序中，有大量的依赖项将无法移植。

@bencyoung

这是一个框架，而不是一个库。 它由大量一起提供的库组成。

我不明白，如果不是可重用的共享库，ASP.NET Core是什么？ 如果使库成为现代且快速的趋势是放弃.NET Standard支持，那么这是一个棘手的消息。 如果Newtonsoft.Json可以运行得更快，它应该只切换到.NET Core 3吗？ 应该是Autofac吗？

我不知道这是多么棘手。 我97％的肯定那些库不会删除框架，因为它们的客户会抱怨。 删除框架的门槛很高，这与我们在.NET Standard 2.0上保留Microsoft.Extensions。*的原因相同。 我同意，如果我们将所有内容移到那里，那将是模糊的，但这不是这里发生的事情。

在某种程度上，这只是形式化了.NET Core中已经存在的现实。 我们将ASP.NET Core与.NET Core一起提供。 在.NET Core上，ASP.NET Core是一个共享框架，而不仅仅是一组软件包。 这些软件包从不与整体产品分开运送，因此引用这些单个软件包的好处很小（顺便说一句，软件包列表也很小）。

@robkeimig

但是，我们还建立了许多服务来利用AspNetCore，这些服务也依赖于诸如System.DirectoryServices和System.Drawing之类的东西。

那些存在于.NET Core https://docs.microsoft.com/zh-cn/dotnet/core/porting/windows-compat-pack上的Windows Compact Pack中

简而言之-这个决定将迫使我们在将来的某个时候（可能是LTS在2.x到期时）完全退出AspNetCore，这是我现在不知道的。 如果涉及到这一点，我们可能会编写自己的内部解决方案来替换AspNetCore，因为就实际使用的AspNetCore功能而言，我们的用例非常狭窄（也就是说，我们利用的功能可以今天对我们来说是一个巨大的附加值）。

如果扩大支持，情况也会这样吗？

此外，现在我们必须首先裁剪所有其他不受支持的技术（AppDomains，Remoting等），而不是能够并行或在以后进行此工作。

为什么不能先迁移到2.1？

我犹豫的最大原因是3年的支持限制意味着您不能留下来。 这是短期迁移的垫脚石，而不是您可以拥有稳定的长期平台的地步。 这意味着您必须一次全部地进行向前迁移的痛苦，因为您不能冒险半途而废，暂停迁移以构建许多高优先级的新功能，然后尝试完成迁移只是为了找到一个难点。必须将所有新功能反向移植到旧代码库。

我犹豫的最大原因是3年的支持限制意味着您不能留下来。

当然，这就是我们提供@DamianEdwards所提供的扩展支持的原因。

只是为了说明这个决定会带来多大的后果-Blazor呢？ 它会停止基于netstandard吗？ 我们也应该期望吗？ Blazor被宣传为下一件大事。 目前依赖于netstandard的github.com/aspnet还有什么，将放弃它并在下一个主要版本中移至net core？ 在MSFT控制下但在ASPNET存储库之外将共享ASPNETCore命运的其他计划是什么？

@davidfowl

其他人可能也会选择其他替代堆栈。

这是公平的，但是替代堆栈具有相同的支持策略。 Java已移至类似的LTS模型（https://www.oracle.com/technetwork/java/javase/eol-135779.html）。

您忽略的一小部分细节是，Java和其他堆栈在.NET Framework和.NET Core不同的版本之间仍然兼容，而无需仅在运行时实现中部分实现的标准。

对于它的价值，我目前正在部署我公司的第一个ASP.Net核心应用程序。 我们对.NET Framework进行了大量投资，因此在.NET Framework上使用ASP.Net Core而不是.NET Core是显而易见的方法。

现在，我想知道以后是否要让我们承受很多痛苦。

这里有很多相互关联的问题。 您说过，ASP.Net核心绝不意味着只能在.NET Framework上运行。 微软过去有关ASP.Net Core的消息未能使这一点变得清晰。

同样，许多.NET开发人员习惯于以.NET Framework为主要实现，而其他人则通常是其子集，当然环境特定的API除外。 .NET Core的情况已经发生了变化，但是许多人普遍认为，“完整的” .NET Framework最终将支持.NET Core几乎所有的功能（显然，除了工具和跨平台兼容性以外）。只是在较慢的时间范围内，等到纠结解决之后再将它们包括在内。

最近，有很多建议认为某些真正重要的功能可能永远不会出现在.NET Framework中。 （例如Span的兼容性风险.NET Framework 4.8中被认为过于严重而无法实现的类型表明它们可能永远不会实现，因为为什么这些风险在4.9中会更低？ 默认接口方法似乎也有类似的问题。）这是一个重大的范式转换，许多开发人员都不满意！

此线程中的消息表明，Microsoft开始将.NET Framework作为一项旧功能，随着时间的推移，该功能将越来越受到开发人员的关注，直到它仅获得安全修复为止。

微软历来对清楚自己在积极开发什么，仅使用零星的新功能进行维护，以及仅打算真正为其提供安全性和稳定性修复的计划一无所知。 在我看来，.NET Framework不仅不属于第二类，而且确实接近于第三类。

真烦人。 .NET Core存在一些问题，使其不适用于某些企业应用程序。 确保在持续不断的开发应用程序上使用它可能会很好。 但是，举例来说，大多数企业也有一些应用程序已被部署，并且仅每隔几年就会被触摸一次。 NET Core无法正常工作。 在这里，企业必须为大多数版本提供较短的支持周期。 而且，在Windows上，目前不存在自动安装新补丁程序版本以获取安全更新等的机制。

因此，开始新项目的企业不知道该怎么做。 更加企业友好的.NET Framework表现出明显过时的迹象，因此更好地避免了新开发。 另一方面，存在.NET Core，但对企业的友好程度大大降低。

因此，这基本上成为了喧嚣，但我希望这能更好地说明许多开发人员所担心的问题。

@davidfowl

但是，我们还建立了许多服务来利用AspNetCore，这些服务也依赖于诸如System.DirectoryServices和System.Drawing之类的东西。

那些存在于.NET Core https://docs.microsoft.com/zh-cn/dotnet/core/porting/windows-compat-pack上的Windows Compact Pack中

我不知道兼容性包支持此用例。 理想情况下，我们希望将所有内容都移至.NET Core，这似乎是一个很好的答案（最初可能被我们忽略了）。 我们没有计划将我们的服务托管转移到Linux / OSX，因此这些部分很适合我们。

如果扩大支持，情况也会这样吗？

在支持方面-考虑到影响深远的所有其他限制，我认为2021年的2.x LTS合理。

根据我现在的理解，一旦我们有机会查看并将.NET Framework项目转换为.NET Core项目（需要使用兼容包），我们可能会很乐意升级到AspNetCore3.x。

感谢您的跟进。

我在高压项目中用.NET（主要是C＃）编写了15年。 我浪费了很多年，客户使用了过度设计的框架却浪费了时间。 我喜欢.NET Core的概念。 对我而言，这是在惊人的.NET生态系统（包括所有繁琐的工作）中编写NodeJS项目的速度。 不幸的是，它未能兑现该承诺，但仍然（即使有新公告）过于复杂，以至于无法流血使用。 在过去的3年中，我一直在NodeJS中进行构建，对不起，这是无法比较的。 使它变得更加简单易用，您将再次吸引广大的开发​​人员社区。

对于具有硬的，已编译的二进制.NET Framework依赖项（没有源代码的供应商资料）的项目，这些项目可以在针对Windows上部署的.NET Framework的ASP.NET Core 2.1应用程序中运行，将向项目添加Windows兼容性包，以使它们继续工作Core 3.0是否提供了包提供的硬依赖关系引用类型？

有一个非常成熟的商业库组成的庞大生态系统，不幸的是，这些库依赖于System.Drawing，GDI甚至有时是注册表（！）。 如果这些现在只能在2.1上使用并且仅支持三年，那么这个问题可能会阻止Core在某些企业中的采用。

.NET Core正在全面发展以达到起点。

我会建议另一种方法：让.NET Framework合并.NET Core的有用功能，然后将.NET Core完全淘汰，作为试验性的死胡同分支。 从而停止细分并节省技术，从而为客户带来更大的利益。 在产品方面有些争议，但要明智得多。

@davidfowl

在.NET Framework上运行的ASP.NET Core从来都不是永久性的，它始终是踏脚石。

那根本不是真的。 一直以来，ASP.NET Core上的消息传递均受.NET Core和.NET Framework的支持。 甚至.NET Core的最早发布都提到了ASP.NET Core的两个平台（早于ASP.NET 5）。

展示.NET Standard的非常著名的“没有计划取消对ASP.NET Core中针对.NET Framework的支持。”

所以，是的，很显然，这个决定已经通过，现在改变了，但说这是总是这样要么只是一个谎言，或通过微软多年来做了非常糟糕的通信。

它甚至被称为ASP.NET Core

哦，拜托在所有这些时间之后，像我这样的人不得不让人们将.NET Core和ASP.NET Core分开，因为它们不是同一回事，在这里不要仅仅使用相似的名称来发挥自己的优势。 那不公平。 名称更改为“ Core”当然不是为了将其显式链接到.NET Core。 此外，EF Core也具有“ Core”，但将继续在netstandard上运行，因此该论据不起作用。

这就是扩展LTS支持的来源。如果应用程序在这6年后仍然无法移至.NET Core […]

从现在开始这到底是哪里来的？ 上一次，该信息仍然是“我们正在研究“扩展支持” LTS产品” 。 现在这是真的吗，我们有6年了？

@pjmlp

您忽略的一小部分细节是，Java和其他堆栈在.NET Framework和.NET Core不同的版本之间仍然兼容，而无需仅在运行时实现中部分实现的标准。

公平的说法，但是我不知道更好的支持有什么用。 有人声称切换到Java会更好，因为减少了残缺的库（这是一个时间点问题）和企业支持（更长的支持周期）。

@凯文·卡斯卡特

此线程中的消息表明，Microsoft开始将.NET Framework作为一项旧功能，随着时间的推移，该功能将越来越受到开发人员的关注，直到它仅获得安全修复为止。

微软历来对清楚自己在积极开发什么，仅使用零星的新功能进行维护，以及仅打算真正为其提供安全性和稳定性修复的计划一无所知。 在我看来，.NET Framework不仅不属于第二类，而且确实接近于第三类。

参见https://blogs.msdn.microsoft.com/dotnet/2018/10/04/update-on-net-core-3-0-and-net-framework-4-8/

对于具有硬的，已编译的二进制.NET Framework依赖项（没有源代码的供应商资料）的项目，这些项目可以在针对Windows上部署的.NET Framework的ASP.NET Core 2.1应用程序中运行，将向项目添加Windows兼容性包，以使它们继续工作Core 3.0是否提供了包提供的硬依赖关系引用类型？

是的，它是二进制兼容的。

有一个非常成熟的商业库组成的庞大生态系统，不幸的是，这些库依赖于System.Drawing，GDI甚至有时是注册表（！）。 如果这些现在只能在2.1上使用并且仅支持三年，那么这个问题可能会阻止Core在某些企业中的采用

正如我在该线程上多次提到的那样。 我们增加了直接引用在.NET Core项目上针对.NET Framework编译的依赖项的功能。

@poke您对消息传递是正确的，我的错误根本不清楚。

从现在开始这到底是哪里来的？ 上一次，该信息仍然是“我们正在研究“扩展支持” LTS产品”。 现在这是真的吗，我们有6年了？

我组成了6，我不知道提供支持时会得到多大的支持。

.NET Core总是要替换.NET Framework （最初是.NET Framework 5），但是重写过程如此雄心勃勃，以至于现在已被利用来支持桌面应用程序。

哇，这里有很多有趣的评论。 似乎有很多放错地方的书呆子怒气，穿插在人们没有阅读这篇文章的地方。

支持

@edandersen您是否在这些外部dll上运行
Windows兼容性包已经提供了用于system.drawing和注册表的功能。 您是否已经尝试在.NET Core上运行这些东西？ System.Drawing甚至可以使用mono的libgdiplus在* nix上运行。 这使我们可以在非Windows系统上使用ClosedXML来处理Excel文件。

WCF功能是我们公司对“最新”应用程序的最大依赖。
.NET Core WCF客户端库正在改进。 我还没有检查它们与我们使用的某些服务的配合情况的当前状态，但是在过去，我们无法与某些服务进行对话。 但是缺少的功能已经在他们的问题列表中。 另一方面，简单的服务效果很好！
另一方面，在.NET Core中没有“替代”替代方法来托管SOAP服务。 这将阻止将某些应用程序迁移到.NET Core（但如前所述-无需这样做）。
对于最近的ASP.NET Core应用程序，我们创建了一个额外的ASP.NET代理Web应用程序，该应用程序仅托管WCF服务，然后通过HTTP / JSON转发到ASP.NET Core应用程序。 它不是很漂亮，并且增加了部署复杂性，但是它允许一些集成点。

我并不是说我真的想要.NET Core中的WCF托管功能，因为配置它时我很头疼。 不过，托管SOAP服务并生成WSDL的某些选项很酷。 我已经看到一些OSS库正在尝试这样做。 也许就足够了。

@davidfowl

公平的说法，但是我不知道更好的支持有什么用。 有人声称切换到Java会更好，因为减少了残缺的库（这是一个时间点问题）和企业支持（更长的支持周期）。

关键是，尽管Java LTS版本也是三年，但所有主要实现之间的兼容性都是金，这是你们愿意在这里抛弃的。

整个.NET Framework，.NET Core，Xamarin，.NET Standard的失误看起来就像WinDev vs DevTools的美好时光，只是在.NET团队内部进行更改。

因此，自然而然地，客户愿意迁移到内部团队看上去并不在争取路线图功能的平台。

这些决定不会激发信心。

在.NET团队看来，这确实感觉像是一个错误，尤其是在当前环境下！

对于那些提到Java的人，您实际上是否看过最近发生的事情？ 从针对Google在Android中使用Google的绝对疯狂诉讼到最新的许可恶作剧之间，Oracle的行为始终表现为一家公司想要杀死不想要的产品，而不是希望它蓬勃发展的公司！

这是Microsoft利用强大的市场营销功能来利用它们的最佳时机，表明他们在做相反的事情，并且.NET是理智，稳定，安全的开发选择的地方。 相反，我们得到了...这个。 ：失望：

@masonwheeler

在这两种环境中工作的我们实际上对Oracle的工作表示赞赏
一直在使用Java。

是那些很少在生产中使用Java，鄙视Oracle的人，
在对他们的仇恨争论中迷失了方向。

在Android方面，作为Google，我完全支持该诉讼
设法派生了Java平台，从而在Microsoft失败的地方成功了
使用J ++。 仍然期待有一天Maven Central中的任何随机JAR都能在Android上实际运行。

至于.NET，我开始厌倦了不断重启
我们应该如何针对Microsoft平台。

整个WinRT，UAP，UWP，.NET Native删除了F＃，XNA，Core 1.0
很多酸葡萄，这个最近的决定并没有使事情变得更好
总体。

.NET是我最喜欢的平台，因此请不要进一步破坏它。

@mythz

现在，我知道2.1是.NET Framework支持的最新LTS版本，这意味着没有地方可以升级到

这意味着它已成为不受支持的平台，它上的任何人都必须像对待熔岩一样对待它，并争先恐后地将其下架，直到它达到其不受支持的EOL端。

这是我在整个讨论中并不真正理解的要点之一。 除了安全修补程序（扩展的LTS支持可能涵盖）之外，您还从LTS支持中真正得到了什么？

在主流LTS支持中，只有两件事可以期待：

• 安全修复
• 严重的错误修正

以前的大多数（安全修复程序）将通过Windows Update进行修补（因为您定位到.NET Framework）。 因此，ASP.NET Core本身仅保留了一些安全性和关键错误修复程序。

假设它已经知道该支持将在2018年结束，我不希望有人在2020年开始新项目，因此（恕我直言）您不太可能在2021年（或2026年）之后发现严重的制止动物的错误，或者这意味着延长支持的期限成为）。

只是留下了安全漏洞，这对于使用LTS来说是合理的。

在以前的答案中，我看到提到TLS 1.4等。无论如何，LTS不会覆盖这些内容，因为无论如何这是一项新功能，即使对于Java而言也是如此（Java 6仅具有TLS 1.0支持-TLS 1.1，如果您将非公开更新，仅适用于Oracle的扩展支持订户）。

• 任何考虑将其用作升级到.NET Core的暂存平台的人都变得不太可行，因为如果迁移花费的时间比预期的长，或者面临任何依赖，他们将面临被困在不受支持的平台上的风险。他们依靠不能在.NET Core上运行。
  但是，您现在可以在.NET Framework上的ASP.NET Core中使用哪些API，但是在.NET Framework +兼容性包上的ASP.NET Core中不能使用哪些API？

我认为这是更关键的一点，要识别出这些缺陷，或者将缺少的API与将来的Compatibility软件包一起运送，或者将它们添加到.NET Core中，从而即使在以.NET Core为目标时也可以引用.NET Framework库。

从.NET Core开始，您可以引用（和使用）.NET Core项目中的任何.NET Framework库，只要它仅使用.NET Standard或.NET Core中可用的API 。

这不需要库作者将其库更新为以netstandard / netcoreapp为目标。

如果Microsoft通过nuget.org上每个nuget包旁边的功能/链接扩展NuGet网页/库，这会有所帮助，该功能/链接会显示此库是否使用了特定版本的.NET Core中不可用的不兼容API的报告？

例如

'Company.Example.MyLib`将显示

• .NET Core 2.1：部分支持（详细报告）-详细报告将在其中显示Apis起作用和不起作用
• .NET Core 3.0 ：； 完全支持

通过运行.NET Portability Analyzer，应该可以做到这一点吗？ 如果能添加一个可以安全调用的公共API列表（如果通过分析IL代码并查看其调用哪些其他API以确保其安全性），那么将是一个加分奖励吗？

至少这将使开发人员更容易确定其项目所需的特定库是否可以在.NET Core上运行，即使它没有显式调用它也是如此？

现在，很难弄清楚是否支持API，您需要该库在其上本地运行分析器。 许多开发人员可能不知道他们可以使用某些不正式支持netstandard的库。

@davidfowl @terrajobst这是否可以作为NuGet的可行补充？ 要使与-NET Core兼容的.NET Framework库的可发现性变得越来越容易和快捷？

• 任何被迫使用企业现有托管基础结构的.NET Framework服务器的人都无法参与使用新的开发人员模型和生态系统，而不得不看到其现有的经典ASP.NET知识/技能的价值每天都在降低。

是否支持.NET Framework几乎不是一个论点。 固守旧式依赖项且无法迁移到.NET Core（带有兼容包或.NET Framework库）的人将无法在此之后做任何事情。 那会如何改变？

尽管如此，整体应用程序的某些部分仍可以拆分，然后逐渐将旧版应用程序的某些部分移至新应用程序，但这是另一回事。

• 任何组织都不想被迫进行计划外的迁移，因为他们用来作为预算，计划和投资决策依据的指南已经改变。

如果收益超过投资，为什么不呢？ 也就是说，如果有独特的功能可以为您带来巨大的价值回报或巨大的性能提升。

如果没有，请继续使用旧系统。 软件开发一直都是这样。 仍然有一些公司运行使用Fortune和Cobol开发的软件。

有很多人不能或不希望使用.NET Core，他们希望它共享与经典ASP.NET相同的支持水平（当前消息表明这是无限期的）。

缺少API并不是阻止迁移的唯一原因，例如，它们可能依赖于开发团队创建它不再存在的依赖关系，这是一个不可更改的关键组件，无法安全重构（例如没有测试），它与其他仅.NET FX的系统共享，由另一个没有预算，无法更改它的部门维护，或者由于外部因素（例如其企业管理的基础架构仅支持在.NET Framework服务器上运行）而维护。

是的，但是哪些依赖项？ 为了确定这些外部依赖项正在使用哪些API，将需要一些具体示例。 该API可以添加到.NET Core 3.0或.NET Core的将来版本中。

这样就可以在.NET Core项目中使用此.NET Framework库。 唯一的问题是.NET Framework库使用的API在.NET Standard或.NET Core中不可用。 但是要修复该反馈，就需要标识库。

@pjmlp

@davidfowl

其他人可能也会选择其他替代堆栈。

这是公平的，但是替代堆栈具有相同的支持策略。 Java已移至类似的LTS模型（https://www.oracle.com/technetwork/java/javase/eol-135779.html）。

您忽略的一小部分细节是，Java和其他堆栈在.NET Framework和.NET Core不同的版本之间仍然兼容，而无需仅在运行时实现中部分实现的标准。

以后的Java版本也不是完全正确的。 Java 9添加了使运行时模块化的第一步，这是一个重大变化。 在版本9中，默认情况下已禁用此功能，但在以后的版本中，默认情况下将启用该标志（或无法将其关闭），这确实会对旧版应用程序造成重大更改。

例如，对于许多确实通过反射魔术使用内部API的库而言，这种更改会并且会因此

@TsengSR

尽管Java 9中引入了重大更改，但所有相关Java框架中的100％都可以在Java 9、10和11上运行，而.NET Framework，UWP和Core绝对不是这种情况。

想象一下，即使有两个正式的跨平台GUI框架，而我们仍然没有Core的正式路线图！

@pjmlp

@TsengSR

尽管Java 9中引入了重大更改，但所有相关Java框架中的100％都可以在Java 9、10和11上运行，而.NET Framework，UWP和Core绝对不是这种情况。

想象一下，即使有两个正式的跨平台GUI框架，而我们仍然没有Core的正式路线图！

抱歉，这完全是废话。

Java 9的内部模块，除非调用--add-opens否则它会阻止反映到这些模块中（iirc一直被认为是一个临时解决方案，因此人们可以继续运行其旧版应用程序，并在以后删除几个版本）。

如果您在Java 9即将实现时错过了戏剧和片段，这是对此的响应：
http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-May/012673.html

为了帮助整个生态系统迁移到模块化Java平台，
我特此提议放宽步伐，允许非法反射进入
默认情况下，从JDK 9中类路径上的代码开始，并在将来的版本。

另外，不推荐使用Java EE 9，不推荐使用JAX-WS，并将在Java EE 11中将其删除。这可以大致等同于WCF。 任何使用它的适用版本都不能移植到新版本，除非用其他东西代替它，这是一个迁移过程。 从.NET Framework上的ASP.NET Core迁移到.NET Core上的ASP.NET Core（或从ASP.NET迁移到ASP.NET Core @ .NET核心），几乎没有什么不同。

https://www.oracle.com/corporate/features/understanding-java-9-modules.html

更高的平台完整性-在Java 9之前，可以在平台中使用许多本不应该由应用程序类使用的类。 通过强大的封装，这些内部API可以真正被封装，并使用该平台对应用隐藏。 如果您的代码依赖内部API，则这可能会使将遗留代码迁移到模块化Java 9成为问题。

使用这些内部API（包括所有旧库确实使用的sun.*命名空间中的所有应用程序，或在Java 9即将发行时用于回用）的任何应用程序，或使用依赖于以下情况的第三方库此API或其他库上的内容可能会受到重大更改。 问题是，就像在.NET Framework和.NET Core中一样，您不会仅从库中看到是否调用了API。

@TsengSR

Java 9的内部模块，除非调用--add-opens（否则iirc一直被认为是一个临时解决方案，所以人们可以继续运行其旧版应用程序并在以后删除几个版本），否则这些模块将无法反映到这些模块中。

或者，您可以使用类路径模式并跳过混乱的模块。 在可预见的将来，这种模式将保持不变。 而且，如果您确实进入了模块，则可以在其他模块的包中显式声明依赖项。

另外，不推荐使用Java EE 9，不推荐使用JAX-WS，并将在Java EE 11中将其删除。这可以大致等同于WCF。

Java 11已弃用并删除了所有J2EE。 但是J2EE只定义接口，而不是实现。 要继续使用我做的J2EE，您只需要切换依赖项即可。 无论如何，所有实现都是独立的，并且在Java 11中可以正常工作。

使用这些内部API（包括所有旧库确实在sun。*名称空间中使用的所有应用程序，或者在Java 9即将发布时用于回用）的任何应用程序，或使用依赖于此API的第三方库否则其他库可能会发生此重大更改。

情况一直如此。 它们是未记录的API。 没有人应该使用过它们，并且它们随时都可能被更改或删除。 为了避免破坏现有程序，保留了许多常用的（内部）内部API，以便将来可以迁移到适当的API。

一些API已被弃用，但我们所谈论的是特定的API，而不是整个JRE或Java生态系统。 从这些API过渡到较新的，官方的和已记录的API所需的工作通常很少。

Java一直比.NET更愿意打破向后兼容性。 例如，在Java中，声明一个名为var的类型现在是非法的，因为该类型保留用于本地推断。 在Java中，命名变量_是非法的，因为保留该变量用作丢弃/通配符。 在两种情况下，C＃都以保留向后兼容性的名义做出了相反的决定。

不要误会我的意思，Java本身就是一团糟。 在模块之间，对Java 8的支持即将结束，并且Oracle对JRE许可感到贪婪，Microsoft拥有大量的机会来转变人们。 但是，如果微软要就其平台的未来支持和发展发表各种不同的消息，那将是不可能发生的。

@TsengSR

这是我在整个讨论中并不真正理解的要点之一。 除了安全修补程序（扩展的LTS支持可能涵盖）之外，您还从LTS支持中真正得到了什么？

在LTS上有一个tick脚的时钟，它的结尾是无处可升级，这是比较中抛出Java LTS时掩盖的关键点。 借助Java和.NET Framework，您始终充满信心，因为他们非常关注向后兼容性，因此您可以以最小的努力升级现有系统。 随着不再有升级途径，现有系统将不得不迁移到新的运行时或在不受支持的平台上继续运行。 由于各种原因，将存在无法迁移到.NET Core的系统（离开该决定）而无法在不受支持的平台上运行其关键业务功能的未来。

不确定此决定最接近的隐喻是在Java领域，也许是迫使现有系统迁移到在GraalVM上运行，很多事情会起作用，有些则不会，系统越大，预测兼容性的信心就越小/问题，直到尝试进行物理迁移为止。

我同意已经做了很多工作来使向.NET Core的迁移成为可能，但是仍然会有很多外部因素（包括MS控制范围之外的因素）会阻止迁移，而这一决定只会使与发布此版本之前相比，迁移的可能性较小。ASP.Core/ FX是一种流行的迁移路径，但是建议整体迁移策略包括迁移到将来不受支持的平台已不再是明智的选择，这将防止许多迁移由于发生这种情况，导致更多的现有系统/设备停滞在停滞的经典ASP.NET中。

以前的大多数（安全修复程序）将通过Windows Update进行修补（因为您定位到.NET Framework）。 因此，ASP.NET Core本身仅保留了一些安全性和关键错误修复程序。

组织不想将其企业建立在部分受支持的平台上，希望将来任何将来的错误或安全问题只会在专门用于支持的库中发生。 如果ASP.Core / FX得到与.NET Framework其余部分相同的支持级别，则这将有很长的路要走，未来任何安全漏洞都将得到解决。

当前只有MS能够修补和发布更新的ASP.Core NuGet软件包，而相互依赖的互连树OSS在这里不会有多大帮助，除非它们收到的2.1 PR（在LTS之后）将得到审核，接受和已发布。

最后，在讨论了所有细节之后，仍然重要的最终问题是：

我们可以继续在ASP.Core / FX上运行现有系统吗？

从技术上讲，这是有可能的，但不能保证将来的关键错误/安全漏洞将得到解决，因此该建议已变为“否”，从而使受影响的外部生态系统吸收了此决定的痛苦。

如果ASP.NET Core仅将成为.NET Core，那么我们应该如何看待整个.NET Standard？

如果Microsoft本身不是出于（无疑是有效的）理由对它押宝，那为什么要这么做呢？

是否会有一流的，最新的.NET Core唯一库和“更简单”的，不太高级的.NET Standard库？

这似乎扼杀了改进任何非.NET-Core平台的动力。

希望有人可以告诉我我错了，可以减轻我的疑虑。

你好
我看到了继续前进的价值，我也很喜欢它，但是我看到有关此决定的3个主要问题：
1）如果微软内部没有人用它制造任何困难，netstandard将是二等公民，如果你们不dog狗，您怎么能要求其他开发人员这样做呢？ 如今，库作者必须非常努力地工作，如果内部ppl不使用该标准，则支持将不会得到改善。
2）在其他运行时中运行aspnet核心具有价值。
3）在旧的运行时中运行的软件中有一些价值（具有永远不会被依赖的依赖性），不应轻易丢弃。

然后是通信：我想每个人都喜欢一个可以在任何地方运行的.net运行时，但是在可预见的将来这是乌托邦的，因此netstandard被创建为代理。 从我的角度来看，每个不是针对网络标准而是针对平台的项目，都是朝着这个愿景的方向迈出的一步。
显然，.net框架处于维护模式，.netcore将取代它（保留一些尸体），而mono将在设备上运行，而且故事和CoreRT都不希望继续前进。

使用netcore 3.0，您可以同时做两件事：支持桌面工作负载和“告诉ppl立即跳转以保持相关性”。 我认为这需要开发人员的一次信念飞跃，而且过于乐观，因为每个人都知道许多项目由于缺少某些依赖项而不会迁移，这很可能会在1-2年的未来3.1 / 3.2版本中添加（非常接近2.1的3个LTS年）。 同时，由于他们无法控制的依赖关系，想要相关的开发人员被禁止使用3.0位。

在ppl测试了该决定并查看其实际含义之后，是否可以推迟该决定？
是否有可能像您规定库作者那样将aspnet核心编译为netstandard和netcoreapp？ 可以在.net框架上运行降低的性能😄

Roslyn现在可以在.NETStandard 2.0-> https://github.com/dotnet/roslyn/pull/30914上运行

那当然算是一件困难的事！

@davidfowl

我相信这将开始严重限制.Net Framework系统未来开发的选择，这些选择由于各种原因而无法迁移，因为社区正在将工作转移到ASP.Net Core。

例如， Identity Server已经迁移到ASP.Net Core，最近关于SignalR未来的文章毫不奇怪地指出，ASP.Net Core SignalR将成为开发工作的未来重点，而ASP.Net SignalR处于维护模式-当时表示它将支持.Net Framework和.Net Core，我希望这是我们将继续看到的趋势。

我知道LTS对ASP.NET Core的支持已经设置为3年，但是对于本地部署，需要更长的生命周期，因为我们必须向客户提供这些支持（4年）。
在此期间，我们需要能够发布包含安全修复程序的补丁，而无需对应用程序进行重大更改。 这是为了与我们的客户保持一致，进行变更控制流程，这需要他们进行广泛的用户接受度测试才能进行更大的变更，因此我们不必进行重大变更，例如在维护模式下迁移到较新版本。

LTS政策是否有可能改变？ 就像Ubuntu的每两年发布一次LTS并获得5年支持的策略一样，尽管我会要求6年以便在进行向新版本移植的工作时允许当前版本获得3年以上的支持。

我知道已经提到了扩展支持，但是我认为这是我们每个客户都必须购买的东西，我认为如果他们的初始安装（在开发，销售过程，UAT等之后）充其量只能说是令人满意的2年的支持。

另外，很好奇如何在.netcore 3.0中对待.netstandard库。
.netstandard的口号是“一个统统所有的库”。
在此之前，它意味着一切。
在此之后，它看起来意味着一点。

只是为了说明这个决定会带来多大的后果-Blazor呢？ 它会停止基于netstandard吗？ 我们也应该期望吗？

谁能澄清一下？

那么对于像Newtonsoft.Json这样的库（可以从高性能中受益）的建议是否建议切换到.NET Core而不是.NET Standard？ 我在那种库和ASP.NET Core之间看不到太多区别。 我们将REST服务嵌入到较大的应用程序中-其中一些可以轻松迁移到.NET Core，而某些则不能。

在我的理解中，如果您想获得新API的优点但又不想失去读者，则库的建议是同时针对.NET Core 3和.NET Standard2.x。

在我的理解中，如果您想获得新API的优点但又不想失去读者，则库的建议是同时针对.NET Core 3和.NET Standard2.x。

我以为前进的道路到处都是标准，目前，我们正处于过渡之中。 但是通过这样的举动，其他人将（或需要）跟随，我们将回到多目标。

.NET Framework和.NET Core担当着相同的角色，因此，我相信ASP.NET Core一定有一天或现在或以后都不会在.NET Framework上运行。

但是，我发现无法在.NET Standard X上运行时遇到了大问题。 坦白地说，我不需要asp.net内核即可在xamarin或unity上运行，但是可以说可以这样做很高兴-这只是在.NET平台上运行的另一组库。 通过分拆，我们将在.NET Core和ASP.NET Core之间实现更紧密的集成，而对于.NET Core 4.5，恐怕我们谴责从DNX 2.0开始的Microsoft.AspNetCore和@davidfowl 。

另一方面，.NET Standard绝对不是一个可以进行试验的地方，很难正确地进行处理，因此我们是否可以妥协？ 使ASP.NET Core当前仅针对.NET Core，但针对.NET Standard的LTS版本是否可行？ 如果API找不到通往.NET Standard的方法，那么真的值得使用它吗？

我们还可以按照您可能打算的方式查看此内容：

• .NET Core适用于控制台/ Web / 3rdparty桌面（标准+ Web特定api）
• Unity适用于游戏（标准+游戏专用API）
• Xamarin适用于设备/桌面（标准+设备/桌面特定的api）

但是谁能推动.NET Standard向前发展呢？ 就像您在资源有限之前所说的那样，因此恐怕没有实际的投入（在我的建议中，通过更改发布LTS使其落入.net core / asp.net核心团队）。 NET标准将很快过时。

对于那些不注意的人，似乎.NET Standard 2.1刚刚放弃了对.NET Framework的支持。

鉴于.NET Standard 2.1中的许多API新增功能都需要更改运行时才能有意义，因此.NET Framework 4.8将保留在.NET Standard 2.0上，而不是实现.NET Standard 2.1。 .NET Core 3.0以及即将发布的Xamarin，Mono和Unity版本将更新为实现.NET Standard 2.1。

https://blogs.msdn.microsoft.com/dotnet/2018/11/05/announcing-net-standard-2-1/

看到.Net Framework成为Silverlight编写者，这让我很痛苦，但对ASP.NET Core而言，对我而言重要的是，它应该以.NET Standard为目标。

作为可能是Core / Standard生态系统中最大的参考应用程序之一，我相信ASP.NET Core有责任成为.Net Standard及其代表的所有美好事物的拥护者。

我认为ASP.NET Core要求对标准进行更改，然后在.NET Core中实现该更改是合理的。

与通过nuget包在.Net Framework中可用的Span等_is_一样，我认为如果ASP.NET Core需要/希望依赖.Net标准中尚未存在的内容，则应该包括这种依赖关系是合理的通过nuget包进入。

最后，我希望（与所有相反的证据相反），将有一个面向.Net Standard 3.0+的.Net Framework 5.0，并将与4.x并排安装。

最后，我希望（与所有相反的证据相反），将有一个面向.Net Standard 3.0+的.Net Framework 5.0，并将与4.x并排安装。

对，就是这样。 这就是我多年来一直在说的话：CLR 2.0架构已经为我们服务了很长一段时间，但是它开始步履维艰，现在是时候进行与Generics相同类型的基本升级了。 进行必要的更改可能会有些痛苦，但是它们是必需的。 以与需要泛型相同的方式，需要使用更强大的新功能进行更新，而将其推迟下去只会使这种痛苦最终恶化，而不会减轻。

这正是.NET Core的本质，而该线程就是暂时的痛苦。

@terrajobst表示不会发生：请参阅主题： https : //twitter.com/terrajobst/status/1059525279431815168?s =19

@gulbanana
是的，除了两件事。

1. 核心不是从Framework升级； 这是一个平行的概念。 它有很多根本无法做的事情，其中​​有很多事情，例如AppDomains，我们被告知不太可能发生。 为了天堂的缘故，我们什至没有工作的Reflection.Emit ！ 考虑到在编译器和代码生成工具中有多么普遍，您会认为这实际上是首要任务之一，但是在这里，我们已经过了4年，但它不起作用！ 这使得认真对待“核心作为.Net Framework的替换/升级”这一概念非常困难。
2. Core并未从根本上升级CLR 2.0风格的运行时。 在“哪些语言建议将从CLR更改中受益？”一文中。 通常，由于缺少功能，我们从用户认为重要的，缺少功能的社区中列出了很多重要信息，即CLR无法支持（或者至少没有大量，丑陋的笨拙来解决CLR的局限性就无法支持）在类型系统中。 核心团队甚至认真对待了该主题中的多少提案？ 又有多少其他项目因为运行该项目的人员不想升级运行时而被立即淘汰？ 我们正在获得DIM，还有其他什么？ 什么都没有

因此，.NET Core不是进行急需的CLR更新的升级的.NET Framework，因为它不是.NET Framework的升级，并且项目团队正在尽一切可能避免更新CLR。 这与字面意思完全相反。

看在天堂的份上，我们什至没有工作中的反思。 考虑到在编译器和代码生成工具中有多么普遍，您会认为这实际上是首要任务之一，但是在这里，我们已经过了4年，但它不起作用！ 这使得认真对待“核心作为.Net Framework的替换/升级”这一概念非常困难。

了解什么是行不通的。 ASP.NET Core和EF在几个地方使用反射发射，因此我不知道有很大的差距。 您能在这里详细说明吗？

至少从2.0开始就存在了。iirc甚至1.0都具有DefineDynamicAssembly，尽管可能不是整套的东西。

我还发现很难认真考虑他们避免更新CLR的想法。 您是否看到大量的工作要做？ https://github.com/dotnet/coreclr/commits/master
由于CLR的更改，有些C＃8语言功能仅在.NET Core上可用。 其中很多反对意见似乎都是陈旧的信息（这很公平，因为微软的计划有时会迅速改变……）

@davidfowl

了解什么是行不通的。 ASP.NET Core和EF在几个地方使用反射发射，因此我不知道有很大的差距。 您能在这里详细说明吗？

诚然，我已经检查了几个月，所以最近可能已经改变了，但是据我所知，可以在内存中创建一个新程序集，但由于涉及到生成的神秘原因而无法将其保存到磁盘中。 PDB文件，这使得Core对诸如我这样的编译器维护者毫无用处。

这个问题解决了吗？ 我很高兴听到它有...

@gulbanna

我还发现很难认真考虑他们避免更新CLR的想法

我的意思是，他们避免以与2.0更新（泛型）相同的方式从根本上升级CLR。

具体来说，他们似乎正在积极地避免任何会为类型系统添加新的基本类型（形状，元类，DU等）或向指令集添加新的IL指令的更改。

@masonwheeler

诚然，我已经检查了几个月，所以最近可能有所改变，但是据我所知，可以在内存中创建一个新程序集，但不能将其保存到光盘中

看看https://github.com/dotnet/corefx/issues/4491 （您过去曾在此处评论过），我认为情况仍然相同。 尽管我认为缺少一个特定功能（即使它是一项重要功能）与“我们甚至还没有有效的Reflection.Emit ”有很大的不同。

这使得Core对像我这样的编译器维护者毫无用处

Reflection.Emit对编译器编写者有何用处？ 我认为这仅限于为当前框架生成程序集，因此根本无法用于创建例如.Net Standard程序集，我认为这对于任何编译器都是一个重大限制。

我的意思是，他们避免以与2.0更新（泛型）相同的方式从根本上升级CLR。

我认为不更改CLR会有一定的惯性，尽管这样做有很多充分的理由，尤其是当您认为此类更改在平台还很年轻时最有用且痛苦最小时。

我认为DIM可能会改变这种情况，但是当JIT内在函数同样可以正常工作时，我仍然不希望有新的IL指令，而在现有的类型系统中可以合理地编码它们时，我也不希望有新的类型。

@svick

尽管我认为缺少一项特定功能（即使它是一项重要功能）与“我们甚至还没有有效的Reflection.Emit”有很大的不同。

如果您有一个文本编辑器可以让您键入文本文件但不保存它们，您是否会说它不起作用？

Reflection.Emit对编译器编写者有何用处？

到目前为止，一切都很好。 据我所知，它是唯一可以使您生成新程序集并保存它们或在内存中生成新程序集并执行它们的编译器后端。

当JIT内在函数同样可以正常工作时，仍然不会期望有新的IL指令

当然可以，但是如果他们不这样做呢？

或可以在现有类型系统中合理编码的新型。

您是否看到了在现有类型系统中实现Shapes的建议？ 没有什么合理的； 从头到尾都是一个很大的丑陋的恶棍。 （不反对提出它的人；考虑到它的工作局限性，一定是必须的。）而且，如果没有CLR级别的支持，实现所有元类都是好运！

我们需要更新的CLR才能以任何一种有效的方式开发更高级别的功能，而实际上没有人致力于在Core上实现这一功能。

.net团队中的某人是否可以澄清他们对本地部署的建议是什么？ 只是“定期使用asp.net”？ 我是专门针对@ Edward84的评论

这会影响Microsoft.Extensions.*支持库吗？ 特别是Microsoft.Extensions.Logging和Microsoft.Extensions.Configuration 。

我们拥有共享通用核心API的大型代码库。 其中一些是WinForms，一些是经典的ASP.NET，一些是WCF等。最新的应用程序是.NET Core（目前还没有，但是最终当我们将核心库移植到.NET标准时）

我们已选择将核心日志记录和配置API基于上述库中的抽象。

因此，我想知道这些是否可以在.NET Core和.NET Framework（4.7.2+）引用的.NET Standard API中安全使用，还是它们也可以开始仅使用.NET Core功能？

@mvestergaard如公告本身所述：

Microsoft.Extensions程序包（例如日志记录，依赖项注入和配置）将继续支持.NET Standard

在此线程中@benaadams的评论中：

并非所有库都仅移至.NET Core（例如， Microsoft.Extensions.*保持为.NET Standard）

正如已经提到的@mvestergaard ，我们正在研究LTS政策，以确定诸如扩大支持，延长期限，“维护模式”期限等之类的内容是否有用以及它们的外观。 我们还在努力寻找是否可以使新LTS列车的时间安排更可预测（我们看到的模型，并真正从具有LTS模型的其他烟囱中欣赏该模型）。

我遇到的最大问题是无法使用仅在定位.NET Framework或仅在.NET Framework之外根本不可用的包（如需要System.Drawing和GDI +的包）时才能使用的成熟包。

似乎.NET Core 3.0将支持后一种情况，但是AFAICT，我们仍然会错过使用只能在.NET Framework上使用的稳定，成熟的库。

实体框架就是一个例子。 我们必须切换到不成熟的EF Core ，这似乎距离处理完整EF可能遇到的所有复杂场景还有很长的路要走，而这又回到了内存中客户评估的背后，以掩盖导致性能下降的问题问题。

实体框架就是一个例子。 我们必须切换到不成熟的EF内核，这似乎与处理完整的EF可以解决的所有复杂情况相去甚远。

EF6将在.NET Core 3.0中得到支持，如@DamianEdwards在本周的ASP.NET Community Standup中所解释的那样-2018年11月6日-ASP.NET Core 3.0功能在19:06

@benaadams真是个好消息！ 这么大的事情真是晦涩！ :)很好地找到了。 在这里找到另一个提及。

@SaebAmini ：您可以使用系统。 在.NET Core上绘图。 参见System.Drawing.Common和Scott Hanselmans博客文章： https ://www.hanselman.com/blog/HowDoYouUseSystemDrawingInNETCore.aspx，

在此之前， CoreCompat.System.Drawing作为Mono的System.Drawing的端口存在。

在.NET Core上运行时，您的用例是否缺少任何功能？

@TsengSR我使我们瞄准.NET Framework的特定场景是：

1. 需要使用Microsoft Solver Foundation程序包，仅在.NET Framework中可用。
2. 使用System.Drawing的条形码图像生成包。
3. 需要使用EF6。

这是大约一年前。

@SaebAmini ：如前所述，.NET Core 3.0中已经提供了EF6支持，并且System.Drawing已经存在（并且在此之前，CoreCompat软件包确实存在并且可能在您的情况下可以使用）以及Microsoft Solver Foundation软件包，之后运行可移植性API分析器：

请参阅如何使用可移植性分析器

https://gist.github.com/TsengSR/f61c03c5f2d63dbe78d6b8c1eed08831 （下载并打开HTML，找不到放置它的其他地方）。

它显示了与.NET Core 2.0 + Platform Extensions（大约一年前发布）的97.93％兼容性，并且列出了不兼容的API，这些API主要与已弃用的System.Web和System.ServiceModel / System.Data.Linq 。

现在，我以前没有使用过此软件包，也不确定为什么求解器需要访问System.Web和HttpContext或System.ServiceModel ，但是如果您不这样做的话不需要任何这些（并且您知道用例没有调用此API），机会很大，您甚至可以在.NET Core 2.0 / 2.1 + Platform Extensions或.NET Core 3.0上使用它如果它没有专门针对netstandard或netcoreapp20目标对象。

因此，从技术上讲，如果EF Core 2.0可以满足您的应用程序需求，那么一年前就可以将应用程序迁移到.NET Core 2.0 + Platform Extensions（当然，这需要一些迁移工作和更新才能工作） EF Core 2.0）。

是的，需要花费更多的精力来分析有问题的库或替换框架的功能（EF6-> EF Core 2.0 / 2.1），但这远非不可能。 我认为人们不会或应该期望将他们的所有代码1：1移植到ASP.NET Core而不进行任何更改（ASP.NET Core本身之外）。

只是希望显示API兼容性会更加明显，例如在nuget页面上的某个位置显示“徽章”（与.NET Core 3.0兼容）和/或详细的api兼容性报告，以使其与不必下载软件包相比更加明显。然后通过包分析器运行它。

我认为，如果强调.NET Core变得更加兼容的话，本公告会更好。 有两个启用因素可以将ASP.NET Core移出.NET Framework：
1）减少对.NET Framework的需求，使旧版dep可用并改善互操作性等
2）增加.NET Core，功能和性能的好处，并减少维护负担

在必须实际构建ASP.NET的人们的脑海中，因素2显得尤为重要！ 但是，从用户的角度来看，没有什么好处。 人们有一件行之有效的事情，而他们最重要的事情就是应该继续工作。 好消息是，在大多数情况下，它会。

我同意@gulbanana。 .NET Core现在与.NET Framework更加兼容。 实际上，仅通过将.exe重命名为.dll并将一些缺少的.DLL添加到探测路径中，我就能启动很大的.NET Framework应用程序。

dotnet命令行工具的进步令人印象深刻。 特别是增加了.NET Core全局工具。 他们使发展变得轻而易举。

crossgen AOT编译很棒。 我可以继续下去。

tl / dr .NET Core如今给人留下了深刻的印象。

什么东西少了：

• 当前缺乏客户沟通策略。 当客户听到他们最喜欢的.NET平台被Microsoft分割成碎片时，他们会感到非常失望。 您应该在这里更加清楚。 例如，将单个，高度兼容，快速且面向未来的.NET实现直接宣传给人们，将是一种更好的方法。 像.NET Core一样，.NET的未来将解决您的大部分问题，飞速的生产力，创造力，开拓新的市场领域等
• 开箱即用的更多兼容性策略
• 图形用户界面。 我的意思是dotnet命令行工具很棒，但是目前我们必须使用其他文本编辑器和控制台来处理.NET SDK格式的几乎每个项目。 在这方面缺少Visual Studio UI。 这给许多习惯于点击的习惯的人设置了很大的障碍。 这也应该改善
• LTS支持

@TsengSR感谢您的详细回复，非常棒的信息！ 当时无法使用条形码包，因为该项目根本不会编译抱怨不同目标的项目。 也许我应该再尝试一次。 （除非您是要自己重新编译并一定要继承它）

如果合理的话，就不用担心付出的努力了。 我主要担心的是，别无选择，而EF是主要的阻滞剂，这似乎不会发生。 很高兴看到它经过深思熟虑。 尽管我同意@gulbanana的观点，但可以更好地宣传这些内容。

这里有很多混淆的问题。 我个人的2美分是，将.NET Framework留在后面并不是什么大问题。 但是，令人担忧的是完全缺乏对标准化工作（.NET Standard）的任何支持。 当然，你可能不希望在运行ASP.NET的核心，说今天统一，但不是今天。 大约一两年后，另一个.NET运行时可能出现，我想说：“是的，只要SuperNetRuntime支持.NET Standard 2.2，我们就可以在其上运行ASP.NET Core 3”。 ...

是否有机会至少“收集” ASP.NET Core 3中的.NET Core 3中所有需要的更改，并将其作为建议转发给.NET Standard工作组？

嗨，将为.NetStandard 2.0或.NetCore 2.0发布的软件包将继续与.NetCore 3.0一起使用。 例如：Oracle.ManagedDataAccess.Core目标.NetCore 2.0

如果存在向后兼容性，则迁移到.NetCore 3.0是合适的，但是如果不支持旧版本，则除非所有方面都赶上了，否则它实际上是无用的。

.NetFramework具有兼容性的历史，即使您可以在最新版本中使用.NetFramework 2.0，因此.NetCore以及至少2.0到3.0等都需要维护。

谢谢

嗨，将为.NetStandard 2.0或.NetCore 2.0发布的软件包将继续与.NetCore 3.0一起使用。 例如：Oracle.ManagedDataAccess.Core目标.NetCore 2.0

是的，.NET Core 3.0保持向后兼容，因此可以使用.NetStandard 1.0-> .NetStandard 2.1和.NetCore 1.0-> .NetCore 2.2库

@benaadams然后多数民众赞成在好。 如果他们不使用任何缺少的api，.net framework dll也将起作用吗？

谢谢

如果他们不使用任何缺少的api，.net framework dll也将起作用吗？

是的，尽管您知道使用.NET Standard库更安全，但可以在.NET Core（以及Mono，Xamarin，Unity，UWP）上使用

此外，使用Windows兼容性包在.NET Standard 2.0的基础上又增加了20,000个API，以使.NET Core更接近.NET Framework（您可以使用.NET Core 2.1来实现）； .NET Core 3.0与EF6（跨平台）最兼容，在Windows上：WinForms，WPF，COM Interop等

嗨伙计，
为了使客户在将应用程序迁移到.NET Core上的ASP.NET Core上有一个合理的垫脚石，我们将扩展对.NET Framework上ASP.NET Core 2.1.x的支持和服务，以匹配当前的支持其他基于包的ASP.NET框架（例如MVC 5.x，Web API 2.x，SignalR 2.x）的策略。 这实际上意味着将无限期支持ASP.NET Core 2.1.x相关程序包（最终详细列表TBD），超过整个.NET Core 2.1培训的3年LTS期限。

好消息。 感谢您聆听您的客户。

自从CTP3以来我们一直使用MVC，并且几乎使用了每个扩展点，要花很长时间才能移植旧的MVC应用程序。 这涵盖了我们的担忧。

@DamianEdwards真是个好消息！ 只是想知道，是否将其固定为2.1.x，或者如果最终成为LTS版本，是否会将其更新为2.2.x？ 2.2版已经投入了大量精力，甚至还没有发布。 而且，由于它可以继续与netstandard兼容并且可以在完整框架上正常运行，因此完全跳过此扩展以获得扩展支持是一种浪费。

@poke，虽然我了解您的担心，但我们必须在某处画一条线，在这种情况下，我们认为最好使版本与之前的LTS保持一致。 这是客户在LTS或Current列车之间进行选择时必须自行决定的折衷方案。 LTS并未涉及新功能，因为它们具有稳定性。 反馈是为了获得长期支持，我们已经为此提供了火车，因此这是火车的延伸。 2.2不会成为LTS。

@DamianEdwards是的，我知道，谢谢您的回复。 我只是问，因为在这最后的评论是，它尚未决定，所以我只是想知道，如果这个扩展支持将发扬IFF 2.2成为LTS。

我认为突出这一点已经足够重要，这样，如果人们不得不依靠这种扩展支持，就不会将其框架应用程序升级到2.2。 否则，他们将不得不再次降级。

LTS并未涉及新功能，因为它们具有稳定性。

但是，这与之前的LTS决定并没有真正的匹配。

@戳

但是，这与之前的LTS决定并没有真正的匹配。

这让我感到困惑。 用什么方式？ 您是否指的是在1.x LTS火车中添加了1.1？ 如果是这样，那将是我们第一个发行火车的异常，不再重复。 展望未来，我们的意图是使LTS与当前版本的发布更加一致（即，我从何处获得稳定性与功能之间的冲突）。

@DamianEdwards我主要指的是，到目前为止，每个发行版都是一个功能强大的发行版，每个LTS决策通常都是经过回顾（至少是公开）。

@戳确定。 好吧，到目前为止，我们已经发布了4个版本（1.0、1.1、2.0、2.1），而第5个版本即将发布（2.2）。 其中，最初仅打算将1.0和2.0用作LTS，但由于许多因素（主要与我们以这种方式进行工程设计非常新new），我们最终以1.0、1.1和2.1作为LTS列车。 2.0和2.2是（将是）当前版本。 在此阶段，在3.1成为3.x火车LTS之前，几乎可以肯定3.0也将是Current（导致2.2进入当前的3个月的“宽限期”）。 我们希望此后，模式和节奏将更加一致（我们希望如此），但到目前为止，我们的水晶球使我们失败了。

@DamianEdwards感谢您的见解！ 😄（顺便说一句，我不是想为此争论，我只是很好奇;））

对我们来说，更大的问题是由旧有应用程序在进程内托管的新REST API，这些API不太可能在不久的将来从.NET Framework移出。 至少我们知道现在不超越.NET Standard 2支持库和ASP.NET Core 2.1！ 延长LTS期限是件好事

嘿，一个简单的问题：我们那些以C ++ / CLI形式使用本机包的人呢？ 是否会很快在.Net Core中支持该功能，还是除非我们进行大量的工作以使用P / Invoke，否则我们将成为孤立的人吗？

@lokitoth-对于https://github.com/dotnet/core人士来说，这将是一个很好的问题，因为它比ASP.NET Core更通用。

@lokitoth是的，将受支持，请参阅https://github.com/dotnet/coreclr/issues/18013

我怎么想念它？

好的，那么我对此没有任何问题。

@ danroth27您能告诉我们此问题对客户端Blazor的影响吗？

@Slkebe我认为不会有任何影响。 客户端Blazor应用程序独立于您决定在服务器上运行的任何运行时或平台。

@ danroth27在我的理解中，客户端Blazor可以在mono上运行，因为依赖的Microsoft.AspNetCore.*软件包的目标是netstandard。
我想念什么吗？ Blazor是否必须继续定位Microsoft.AspNetCore.* 2.1.X？

@Slkebe客户端Blazor库仅取决于将继续以.NET Standard为目标的组件（例如Microsoft.Extensions。*和朋友）。 Blazor的依赖于ASP.NET Core的服务器端部分将针对此问题中所述的.NET Core。

https://blogs.msdn.microsoft.com/dotnet/2018/11/05/announcing-net-standard-2-1/

现在有什么决定？ 针对.net标准2.1？

@ John0King没有新决定。

这是香蕉！ 香蕉

我很同情你的观点。

抱歉，如果这已经提起过，那么在我只想将Kestrel +一些中间件用作非ASP.NET应用程序的一部分的用例中呢？ 我是否必须引入整个3.0树（这不理想，因为我的用例涉及为消费者定义自定义SDK），还是3.x不支持该用例？

由于包含的库，当前我正在开发在.NET Framework上运行的ASP.NET Core应用程序。 我正在使用ASP.NET Core，因为它具有多重身份验证功能。 我感觉上当了，死锁了。

我正在使用ASP.NET Core，因为它具有多重身份验证功能。

@FlorianGrimm具体是什么？ Microsoft.Owin为ASP.NET 4提供了类似的身份验证功能。

它是一个混合应用程序，一个源代码（.exe）在本地和Azure上运行，当前使用Windows身份验证，AAD，基本身份验证和匿名。

@FlorianGrimm哪些库依赖项阻止您使用.NET Core？

Microsoft.Office.Project.Schema，Microsoft.SqlServer.TransactSql.ScriptDom和Microsoft.SharePointOnline.CSOM。

我希望SharePoint团队能够完成
https://sharepoint.uservoice.com/forums/329220-sharepoint-dev-platform/suggestions/16585795-support-net-core-with-csom
我发现除了ilspy以外的其他选择。

我喜欢ASP.NET Core的任何方式，希望其他Microsoft团队将提供更多.NET Core程序集。

我们会定期关闭长时间未更新的“讨论”问题。

如果给您带来不便，我们深表歉意。 我们要求如果您仍然遇到问题，请记录一个包含更新信息的新问题，我们将进行调查。