[翻譯] .NET Core 2.1 Preview 1 發佈

[翻譯] .NET Core 2.1 Preview 1 發佈

原文: Announcing .NET Core 2.1 Preview 1

今天，咱們宣佈發佈 .NET Core 2.1 Preview 1。這是 .NET Core 2.1 的第一個公開發布。咱們有很大的改進但願分享出來，而且渴望獲得您的反饋意見，不管是在評論中仍是在github中dotnet/core #1297

ASP.NET Core 2.1 Preview 1 和 Entity Framework 2.1 Preview 1 也會在今天發佈。

您能夠在 Windows，MacOS 和 Linux 上下載並開始使用 .NET Core 2.1 Preview 1：

• .NET Core 2.1 Preview 1 SDK — 包含 Runtime
• .NET Core 2.1 Preview 1 Runtime

您可使用 Visual Studio 2017 15.6 Preview 6 及更高版本或 Visual Studio Code 來開發 .NET Core 2.1 應用程序。咱們預計 Visual Studio for Mac 將在 15.7 版本支持。

ASP.NET Core 2.1 預覽版不會自動部署到 Azure 應用服務。相應的，您能夠經過一點點配置來實現部署到 Azure。

Visual Studio Team Service 將在 .NET Core 2.1 RTM 發佈時支持。

您能夠在 .NET Core 2.1 Preview 1 發行說明中看到該發行版的完整詳細信息。發行說明中包含已知問題和解決方法。

很是感謝幫助發佈的每一個人。若是沒有你，咱們不可能走到如今，當咱們一塊兒工做到 .NET Core 2.1 RTM 時，咱們會繼續須要你的幫助。

如今讓咱們來看看 .NET Core 2.1 Preview 1 發佈中的許多改進。與 .NET Core 2.0 同樣，它的發行版本很大，你會找到多項改進措施，以便讓你升級。

主題

.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，這些都有助於提供此首次預覽版。