[翻译] .NET Core 2.1 Preview 1 发布

时间  2020-05-10 标签 翻译 core 2.1 preview 发布

[翻译] .NET Core 2.1 Preview 1 发布

原文: Announcing .NET Core 2.1 Preview 1linux

今天，咱们宣布发布 .NET Core 2.1 Preview 1。这是 .NET Core 2.1 的第一个公开发布。咱们有很大的改进但愿分享出来，而且渴望获得您的反馈意见，不管是在评论中仍是在github中dotnet/core #1297ios

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

您能够在 Windows，MacOS 和 Linux 上下载并开始使用 .NET Core 2.1 Preview 1：github

您可使用 Visual Studio 2017 15.6 Preview 6 及更高版本或 Visual Studio Code 来开发 .NET Core 2.1 应用程序。咱们预计 Visual Studio for Mac 将在 15.7 版本支持。web

ASP.NET Core 2.1 预览版不会自动部署到 Azure 应用服务。相应的，您能够经过一点点配置来实现部署到 Azure。docker

Visual Studio Team Service 将在 .NET Core 2.1 RTM 发布时支持。shell

您能够在 .NET Core 2.1 Preview 1 发行说明中看到该发行版的完整详细信息。发行说明中包含已知问题和解决方法。json

很是感谢帮助发布的每一个人。若是没有你，咱们不可能走到如今，当咱们一块儿工做到 .NET Core 2.1 RTM 时，咱们会继续须要你的帮助。windows

如今让咱们来看看 .NET Core 2.1 Preview 1 发布中的许多改进。与 .NET Core 2.0 同样，它的发行版本很大，你会找到多项改进措施，以便让你升级。api

主题

.NET Core 2.1 的发布旨在改进如下主题:

  • 更快的构建性能
  • 缩小 ASP.NET Core 和 EF Core 之间差距 (原文: Close gaps in ASP.NET Core and EF Core)
  • 改进与 .NET Framework 的兼容性
  • GDPR 和安全
  • 微服务和Azure
  • 更强大的工程系统

这些主题的一些改进还没有在 Preview 1 中进行。这些主题会指引咱们接下来的工做。

全局工具

.NET Core 如今有一个新部署和扩展机制。这种新体验与 NPM 全局工具很是类似，而且受到 NPM 全局工具的启发。

使用如下命令，您可使用咱们发布的名为 dotnetsay 的示例工具自行尝试 .NET Core 全局工具（在您安装 .NET Core 2.1 Preview 1 以后）：

dotnet install tool -g dotnetsay
dotnetsay

一旦你安装了dotnetsay，你能够直接使用它，只需在你的命令提示符或终端中输入dotnetsay便可。您能够关闭终端会话、在终端中切换驱动器、或者从新启动机器，命令仍然在那里。 dotnetsay 如今在你的 path 里。检查 %USERPROFILE%\.dotnet\tools 或~\.dotnet\tools 来查看计算机上的工具安装位置。

您能够经过查看 donetsay 工具示例 来建立本身的全局工具。 You can create your own global tools by looking at the donetsay tools sample.

.NET Core 工具是 .NET Core 控制台应用程序，它们是做为 NuGet 包打包和获取的。默认状况下，这些工具是框架依赖的应用程序，并包含其全部的 NuGet 依赖项。这意味着默认状况下，给定的全局工具将在任何操做系统或芯片架构上运行。假如您须要在新版本的 Linux 上使用现有工具，只要 .NET Core 在那里工做，您应该可以运行该工具。

目前，.NET Core Tools 仅支持全局安装，而且须要安装-g参数。咱们也在进行各类形式的本地安装，但这些尚未准备好在 Preview 1 中。

咱们指望有一个全新的工具生态系统来为完善 .NET 自身。其中一些工具将专门针对 .NET Core 开发，其中许多工具将具备通用性。这些工具被部署到 NuGet。默认状况下，使用 dotnet tool install 在 NuGet.org 上查找工具。

若是你对 dotnetay 很好奇，它是仿照 docker/whalesay 的， 进一步是仿照 cowsay 的。 dotnetsay 只是一个 dotnet-bot，他是咱们最忙碌的开发人员之一！

构建性能优化

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

下面的图表提供了您能够重新版本中得到的改进的具体数字。您能够看到 .NET Core 2.0，.NET Core 2.1 Preview 1 以及咱们预期 .NET Core RTM 中会达到的数值。

您能够尝试在 mikeharder/dotnet-cli-perf 中自行构建相同的代码，你会获得相似的结果。请注意，这些改进是针对增量构建的，所以您只能在第二次构建以后看到好处。

次要版本前滚

您如今能够在相同主要版本范围内的较新运行时版本上运行 .NET Core 应用程序。 例如，您将可以在. NET Core 2.1 上运行 .NET Core 2.0 应用程序，或者在 .NET Core 2.5 上运行 .NET Core 2.1 应用程序（若是咱们提供这种版本的话）。前滚行为仅适用于次要版本。例如，.NET Core 2.x 应用程序永远不会自动前滚到 .NET Core 3.0 或更高版本。

若是预期的 .NET Core 版本可用，则使用它。 若是预期的 .NET Core 版本在给定的环境中不可用，则前滚行为仅与此相关。

您可使用以下参数禁用次要版本前滚

  • 环境变量: DOTNET_ROLL_FORWARD_ON_NO_CANDIDATE_FX=0
  • runtimeconfig.json: rollForwardOnNoCandidateFx=0
  • CLI: –roll-forward-on-no-candidate-fx=0

Sockets 性能和 HTTP 托管处理程序

咱们对 .NET Core 2.1 中的 sockets 进行了重大改进。sockets 是传出和传入网络通讯的基础。在 .NET Core 2.0 中，ASP.NET Kestrel Web 服务器和 HttpClient 使用 native sockets，而不是 .NET Socket 类。咱们正在改变这种情况，取而代之的是在 .NET sockets 上创建更高层次的网络 API。

咱们在 Preview 1 中对 sockets 作了三项重要的性能改进：

  • 支持 Socket/NetworkStream 中的 Span<T>/Memory<T>
  • 改进了 Windows 和 Linux 上的性能, 这得益于各类修复(例如重用 PreAllocatedOverlapped、linux 上的缓存操做对象、linux epoll 通知的改进调度等)
  • 改进了 SslStream 的性能, 以及支持 ALPN (HTTP2 所需) 和精简 SslStream 设置。

对于 HttpClient，咱们完全从新构建了一个名为 SocketHttpHandler 的托管 HttpClientHandler。正如你可能猜到的那样，它是基于 .NET sockets 和 Span <T> 的 HttpClient 的 C＃ 实现。

SocketHttpHandler 最大的胜利就是性能。它比现有的实现快得多。还有其余好处：

  • 消除对 libcurl (linux) 和 WinHTTP (Windows) 的平台依赖性 - 简化了开发、部署和服务

  • 跨平台和平台/依赖项版本的一致行为。(原文：Consistent behavior across platforms and platform/dependency versions)

在 Preview 1 中，您能够选择使用如下方式之一来使用 SocketHTTPHandler：

  • **环境变量: **COMPlus_UseManagedHttpClientHandler=true
  • **AppContext: **System.Net.Http.UseManagedHttpClientHandler=true

在 Preview 2 (或 GitHub master 分支) 中, 您将可以按照您所但愿的那样去new一个处理程序: new HttpClient(new SocketsHttpHandler())。咱们还考虑将新的处理程序设置为默认的, 并将现有的 native handler (基于 libcurl 和 WinHTTP) 做为可选的。

咱们仍在努力将 Kestrel 迁移到 sockets。咱们尚未肯定计划来分享给你们，但您能够自行使用 Sockets 来测试 ASP.NET Core。

您可能想知道在传入和传出场景之间如何共享 sockets 改进的, 由于它们感受很是不一样。其实很简单。若是您是客户端, 则在服务器上进行链接。若是您是服务器, 则侦听并等待链接。一旦创建了链接, 数据就能够两种方式流动, 这从性能的角度来看是相当重要的。所以, 这些 socket 改进应改善这两种状况。

Span<T>, Memory<T> and friends

咱们正在引入一组新的类型来更高效的使用数组和其余类型的内存。它们包含在 Preview 1 中。今天，若是您想传递10,000元素数组的前1000个元素，则须要复制这1000个元素并将该副本传递给调用者。这种操做在时间和空间上都很昂贵。新的 Span <T> 类型使您能够提供该数组的虚拟视图，而无需时间或空间开销。这也是一个 struct，这意味着没有分配成本。

Span <T>和相关类型提供了来自众多不一样来源（如数组，堆栈分配和原生代码）的统一内存表示。凭借其分片功能，能够避免在许多状况下进行昂贵的复制和分配，如字符串处理，缓冲区管理等，而且为不安全的代码提供了安全的替代方案。咱们预计这些类型将在性能要求较高的场景中首先使用，但随后会取代数组，做为管理 .NET 中大型数据块的主要方式。

就用法而言，您能够从数组中建立一个Span <T>：

var arr = new byte[10]; 
Span<byte> bytes = arr; // Implicit cast from T[] to Span<T>

经过使用 span 切片方法的重载, 您能够轻松高效地建立一个范围来表示/指向此数组的子集。从那里, 您能够索引到结果范围内, 以便在原始数组的相关部分中写入和读取数据:

Span<byte> slicedBytes = bytes.Slice(start: 5, length: 2);
slicedBytes[0] = 42;
slicedBytes[1] = 43;
Assert.Equal(42, slicedBytes[0]);
Assert.Equal(43, slicedBytes[1]);
Assert.Equal(arr[5], slicedBytes[0]);
Assert.Equal(arr[6], slicedBytes[1]);
slicedBytes[2] = 44; // Throws IndexOutOfRangeException
bytes[2] = 45; // OK
Assert.Equal(arr[2], bytes[2]);
Assert.Equal(45, arr[2]);

Jared Parsons 他的频道9视频中提供了一个很棒的介绍 C# 7.2: Understanding Span. Stephen Toub 有更详细的介绍在这个文章里 C# – All About Span: Exploring a New .NET Mainstay.

Windows Compatibility Pack

将现有代码从 .NET Framework 中移植到 .NET Core 时, 可使用新的 Windows 兼容性包。与 .NET Core 中提供的内容相比, 它提供了额外的 20000 个 API。这包括System.Drawing, EventLog, WMI, 性能计数器和 Windows 服务。

下面的示例演示如何使用 Windows 兼容性包提供的 API 访问 windows 注册表。

private static string GetLoggingPath()
{
    // Verify the code is running on Windows.
    if (RuntimeInformation.IsOSPlatform(OSPlatform.Windows))
    {
        using (var key = Registry.CurrentUser.OpenSubKey(@"Software\Fabrikam\AssetManagement"))
        {
            if (key?.GetValue("LoggingDirectoryPath") is string configuredPath)
                return configuredPath;
        }
    }

    // This is either not running on Windows or no logging path was configured,
    // so just use the path for non-roaming user-specific data files.
    var appDataPath = Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData);
    return Path.Combine(appDataPath, "Fabrikam", "AssetManagement", "Logging");
}

平台支持

咱们指望为 .NET Core 2.1 支持如下操做系统：

  • Windows Client: 7, 8.1, 10 (1607+)
  • Windows Server: 2008 R2 SP1+
  • macOS: 10.12+
  • RHEL: 7+
  • Fedora: 26+
  • openSUSE: 42.3+
  • Debian: 8+
  • Ubuntu: 14.04, 16.04, 17.10+
  • SLES: 12+
  • Alpine: 3.6+

Docker

对于 Docker， 在 microsoft/dotnet 上咱们相对于 2.0 作了一些修改：

  • 添加了 Alpine runtime 和 SDK 镜像 (x64).
  • 添加了 Ubuntu Bionic/18.04, 用于 runtime 和 SDK 镜像 (x64 and ARM32).
  • 从 debian:stretch 切换到 debian:stretch-slim 的 runtime 镜像. (x64 and ARM32).
  • 放弃 debian:jessie (runtime and SDK).

这些变化在某种程度上是基于咱们在过去六个月中听到的两个重复的反馈信息：

  • 提供更小的镜像，尤为是 runtime
  • Provide images with less surface area and/or more frequently updated (than Debian), from a vulnerability standpoint.

咱们还重写了 .NET Core Docker 示例 的说明和代码。 这些示例提供了更好的说明，并实现了更多场景，如单元测试和使用 docker registries。 咱们但愿您找到有用的示例，而且咱们计划继续扩展它们。 告诉咱们您但愿咱们添加哪些内容以使 .NET Core 和 Docker 更好地协同工做。

尾声

感谢您尝试 .NET Core 2.1 Preview 1. 请尝试在现有的应用程序中使用 .NET Core 2.1 Preview 1，而且请试用本文介绍的新功能。 咱们已经付出了不少努力使它们更好，但咱们须要您的反馈让它们跨过终点线，以便最终发布。

再一次感谢全部为发布作出贡献的人。 咱们很是感谢您提供的全部问题和PR，这些都有助于提供此首次预览版。

联系我们 沪ICP备13005482号-10