.NET Core 2.1 Preview 2发布

我们今天宣布发布 .NET Core 2.1 Preview 2。这也是我们在接下来的两到三个月内接近最终发布的版本，该版本现已准备好进行广泛的测试。我们希望您有任何反馈意见。

ASP.NET Core 2.1 Preview 2和Entity Framework 2.1 Preview 2也在今天发布。

您可以在Windows，MacOS和Linux上下载并开始使用.NET Core 2.1 Preview 2：

.NET Core 2.1 Preview 2 SDK (包括运行时)
.NET Core 2.1 Preview 2 Runtime

您可以在.NET Core 2.1 Preview 2发行说明中看到该发行版的详细信息。发行说明中包含已知问题和解决方法。

您可以使用Visual Studio 2017 15.7 Preview 1或更高版本或Visual Studio Code 开发.NET Core 2.1应用程序。我们期望Visual Studio for Mac将在.NET Core 2.1 RTM 发布时增加支持。

非常感谢你一直以来参与我们的测试工作，直到我们发布.NET Core 2.1 RTM，我们将继续需要你的帮助。

构建性能优化

.NET Core 2.1 中的构建时性能得到了很大的提升，特别是对于增量构建。这些改进同时适用于命令行上的dotnet build 和 Visual Studio 中的构建。我们对 CLI 工具和 MSBuild 进行了改进，以使这些工具提供更快的体验。

下面的图表提供了您可以从.NET Core 2.0 以来所获得的改进的具体数字。我们专注于大型项目。

640?wx_fmt=png&wxfrom=5&wx_lazy=1

这些改进来自许多变化，包括以下几点：

加快包资源解决方案
加快增量包资源解析
重用MSBuild节点
缓存MSBuild ResolveAssemblyReferences

如果您没有看到使用.NET Core 2.1 Preview 2的显着改进，我们很高兴看看您的项目。

长时间运行的SDK构建服务器

我们将长时间运行的服务器添加到.NET Core SDK中，以提高常见开发操作的性能。其中一些是移植自.NET Framework，另一些是新的。

已经添加以下SDK构建服务器：

VBCSCompiler
MSBuild worker processes
Razor server

这些服务器的主要优势是，它们可以避免在每次dotnet build调用时都需要JIT编译大量代码。它们会在一段时间后自动终止。

您可以通过以下命令手动终止构建服务器进程：

dotnet buildserver shutdown

这个命令可可以在CI脚本中使用，以便在完成构建之后终止工作进程。您也可以运行构建dotnet build -nodeReuse:false以阻止创建MSBuild工作进程。

新的SDK命令

以下工具已添加到SDK中：

dotnet watch
dotnet dev-certs
dotnet user-secrets
dotnet sql-cache
dotnet ef

我们发现这些工具非常受欢迎行，不把它们添加到单个项目中似乎不是正确的设计，所以我们将它们作为SDK的一部分。

这些工具以前是DotNetCliToolReference工具。他们不再以这种方式交付。当您采用.NET Core 2.1时，您可以删除项目文件中DotNetCliToolReference的条目。

全局工具

.NET Core 现在有一个新部署和扩展机制。这种新体验与 NPM 全局工具非常相似，并且受到 NPM 全局工具的启发。

对于预览版2，全局工具的语法已更改，如以下示例中所示：

dotnet tool install -g dotnetsay 
dotnetsay

您可以通过查看 donetsay 工具示例来创建自己的全局工具，（在安装.NET Core 2.1 Preview 2之后）。

新工具参数

所有工具操作现在都使用该dotnet tool命令。Preview 2中添加了以下新功能：

dotnet tool install - 安装一个工具
dotnet tool update - 卸载并重新安装工具，并对其进行有效更新
dotnet tool uninstall - 卸载一个工具
dotnet tool list - 列出当前安装的工具
--tool-path - 为每个调用指定一个特定的位置以（un）安装和列出工具

次要版本前滚

从2.0开始可以在相同主要版本范围内较新运行时版本上运行 .NET Core 应用程序。您可以在.NET Core 2.1 Preview 1文章中了解有关该行为的更多信息。

但是，.NET Core对于预览版具有相反的行为。包括全局工具在内的应用程序不会从一个预览转到另一个预览，或从预览到RTM。这意味着您需要发布全局工具的新版本以支持后期预览和RTM。

预览策略有点争议。背后的原因是我们可能会在给定的预览版和最终的RTM版之间做出破坏性的变更。这一策略使我们能够做到这一点，同时尽量减少生态系统的破损。还有一种可能的情况是，为预览而构建的软件没有使用RTM构建进行测试，但是，这种基本原理不太引人注目。

自.NET Core项目启动以来，该策略已经实施。全局工具使其更具挑战性。我们非常感谢您对此的反馈和洞察力。

Sockets 性能和 SocketsHttpHandler

我们对.NET Core 2.1中的Sockets 进行了重大改进。Sockets 是传出和传入网络通信的基础。.NET Core 2.1中的更高层级网络 API（包括HttpClient和Kestrel）现在基于.NET sockets.。在早期版本中，这些更高级别的API基于原生网络实现。

我们从头建立了一个新的管理的HttpMessageHandler，叫做SocketsHttpHandler。它是基于.NET套接字和Span <T>的HttpMessageHandler的实现。

SocketsHttpHandler现在是HttpClient的默认实现。SocketsHttpHandler最大的成就就是性能。它比现有的实现快得多。还有其他好处，例如：

消除了libcurl（用于Linux和MacOS）和WinHTTP（用于Windows）的平台依赖关系- 简化了开发，部署和服务。
跨平台和平台/依赖版本的一致行为。

您可以使用以下某种机制来配置进程以使用旧版本HttpClientHandler：

从代码中，使用AppContext类：

AppContext.SetSwitch（“System.Net.Http.UseSocketsHttpHandler”，false）;

AppContext开关也可以通过配置文件进行设置。

通过环境变量也可以达到同样的效果DOTNET_SYSTEM_NET_HTTP_USESOCKETSHTTPHANDLER。要退出，请将该值设置为false或0。

在Windows上，您可以选择使用WinHttpHandler或SocketsHttpHandler以逐个调用为基础。为此，请实例化其中一种类型，然后在实例化时将其传递给HttpClient。

在Linux和MacOS上，您只能在进程基础上配置HttpClient。在Linux上，如果您想使用旧的HttpClient实现，则需要自己部署libcurl。如果您的计算机上安装了.NET Core 2.0，则libcurl已安装。

自包含的应用程序服务

dotnet publish 现在用服务运行时版本发布自包含应用程序。当您使用新SDK发布自包含应用程序时，您的应用程序将包含该SDK已知的最新服务运行时版本。当您升级到最新的SDK时，您将使用最新的.NET Core运行时版本进行发布。这适用于.NET Core 1.0运行时和更高版本。

自包含发布依赖于NuGet.org上的运行时版本。你不需要在你的机器上有服务运行时。

使用.NET Core 2.0 SDK，自包含应用程序将与.NET Core 2.0.0 Runtime一起发布，除非通过RuntimeFrameworkVersion属性指定了不同的版本。有了这种新行为，您将不再需要设置此属性来为自包含应用程序选择更高的运行时版本。最简单的方法是始终使用最新的SDK发布。

Docker

我们正在整合我们用于.NET Core和ASP.NET Core的一系列Docker Hub存储库。我们将使用microsoft / dotnet作为我们唯一的.NET Core资源库。

公开可用的统计数据表明，大多数用户已经在使用dotnet回购，正如您通过以下泊坞扣拉取徽章所看到的那样：

microsoft/dotnet ->
microsoft/aspnetcore ->
microsoft/aspnetcore-build ->

您可以通过aspnet / announcements＃298了解有关此更改以及如何适应的更多信息。

我们还为.NET Core Docker镜像添加了一组环境变量，适用于2.0及更高版本。这些环境变量可以让更多方案无需其他配置即可工作，例如在容器中开发ASP.NET Core应用程序。

To sdk images (example)
- ASPNETCORE_URLS=http://+:80
- DOTNET_RUNNING_IN_CONTAINER=true
- DOTNET_USE_POLLING_FILE_WATCHER=true
To Linux runtime-deps images (example)
- ASPNETCORE_URLS=http://+:80
- DOTNET_RUNNING_IN_CONTAINER=true
To Windows runtime images (example)
- ASPNETCORE_URLS=http://+:80
- DOTNET_RUNNING_IN_CONTAINER=true