[翻譯].NET Core 3 Preview1和Windows桌面框架開源

原文來自TechViews

今天，我們宣佈推出.NET Core 3 Preview 1.這是.NET Core 3的第一個公開發佈。我們有一些令人興奮的新功能可供分享，並希望得到您的反饋。您可以使用Visual Studio 2019 Preview 1，Visual Studio for Mac和Visual Studio Code開發.NET Core 3應用程式。

立即在Windows，Mac和Linux上下載並開始使用.NET Core 3 Preview 1 。

您可以在.NET Core 3 Preview 1發行說明中查看該發行版的完整詳細信息。 請在評論或 dotnet / core＃2099中 報告您發現的任何問題 。

Visual Studio 2019將是支持構建.NET Core 3應用程式的版本， 今天也發佈了預覽版，因此我們也鼓勵您查看它。

.NET Core 3是一項重大更新，它增加了對使用Windows Presentation Foundation（WPF），Windows窗體和Entity Framework 6（EF6）構建Windows桌面應用程式的支持。 ASP.NET Core 3支持使用Razor組件進行客戶端開發。 EF Core 3將支持Azure Cosmos DB。它還將包括對C＃8和.NET Standard 2.1的支持等等！

.NET Framework 4.8

在深入研究.NET Core 3之前，我們先來看看.NET Framework。明年我們將發佈.NET Framework 4.8。隨著支持4K和8K解析度的顯示器，我們正在為WPF和Windows Forms的高DPI添加更好的支持。許多.NET應用程式使用基於舊版Internet Explorer和Windows Media Player的瀏覽器和媒體控制項。我們正在添加使用Windows 10中最新瀏覽器和媒體播放器的新控制項，並支持最新標準。 WPF和Windows Forms應用程式可以通過XAML Islands訪問Windows UI XAML庫（WinUI），以獲得現代外觀和觸摸支持。 Visual Studio 2019基於.NET Framework並使用了許多這些功能。有關.NET Framework 4.8的更多信息，請參閱我們的帖子： .NET Core 3.0和.NET Framework 4.8上的更新 。

Windows桌面來自.NET Core

.NET Core的前兩個版本主要側重於支持Web應用程式，Web API，IoT和控制台應用程式。 .NET Core 3增加了對使用WPF和Windows Forms框架以及現代控制項構建Windows桌面應用程式的支持，以及通過XAML Islands從Windows UI XAML庫（WinUI）構建的Fluent樣式。

今天許多桌面應用程式使用Entity Framework進行數據訪問，因此我們也支持.NET Core 3上的Entity Framework 6。這些框架使開發人員能夠構建Windows桌面應用程式，以利用.NET Core中的新功能，例如並行部署，自包含應用程式（在應用程式內部運行.NET Core），CoreFX的最新改進等。

WPF，Windows窗體和WinUI Open Sourced

2014年11月12日，我們宣佈了.NET Core的開源。它取得了巨大的成功。 .NET平臺已經收到來自微軟以外的3700多家公司的超過60,000個社區接受的拉取請求。

今天，我們很高興地宣佈開源WPF ， Windows Forms和WinUI ，因此三種主要的Windows UX技術將是開源的。有史以來第一次，社區將能夠看到WPF，Windows Forms和WinUI的開發在公開場合發生，我們將在.NET Core上為這些框架做出貢獻。第一波代碼將於今天在GitHub上發佈，未來幾個月將出現更多代碼。

WPF和Windows Forms項目由.NET基金會管理，該基金會今天也宣佈了更改，以便社區直接指導基礎運營。它還通過歡迎Pivotal，Progress Telerik和Insight來擴大目前的贊助商 - 紅帽，JetBrains，谷歌，Unity，微軟和三星。這種新結構將有助於.NET Foundation擴展以滿足不斷增長的.NET開源生態系統的需求。

真的是成為.NET開發人員的激動人心的時刻！

WPF和Windows窗體

WPF和Windows窗體現在可以與.NET Core一起使用。它們出現在一個名為“Windows桌面”的新組件中，該組件是Windows版本的SDK的一部分。

我們一直在與社區開發人員合作，他們已經在早期版本的.NET Core 3上運行他們的Windows桌面應用程式。他們給了我們很好的反饋，WPF和Windows Forms API相容並且他們已經成功！

• .NET Core 3入門 - 創建WPF應用程式
• Greenshot成為了dotnet的核心！ - 推特
• NuGet Package Explorer v5，已經是.NET Core 3 WPF應用程式
• 使用Desktop Bridge打包.NET Core應用程式
• Hello .NET與MahApps.Metro一起使用
• NETworkManager .NET核心埠

您可以從命令行為WPF和Windows窗體創建新的.NET Core項目。

 dotnet new wpf

dotnet new winforms 

創建項目後，您可以運行它們。下圖說明瞭新的WPF應用程式的外觀。

Windows窗體非常相似，如下圖所示。

您還可以在Visual Studio 2019 Preview 1中打開，啟動和調試WPF和Windows窗體項目。目前可以在Visual Studio 2017 15.9中打開.NET Core 3.0項目，但是，它不是受支持的場景（並且您需要啟用預覽 ）。

新項目與現有的.NET Core項目相同，只增加了幾個。以下是基本.NET Core控制台項目與基本Windows窗體和WPF項目的比較。

在.NET Core控制台項目中，該文件使用Microsoft.NET.Sdk SDK並通過netcoreapp3.0目標框架聲明對.NET Core 3.0的依賴：

WPF和Windows窗體項目看起來很相似，但使用不同的SDK並使用屬性來聲明正在使用的UI框架：

對於WPF：

對於Windows窗體：

該UseWPF和UseWindowsForms屬性允許一個項目，指定是否使用Windows窗體或WPF。這將允許工具（例如Intellisense，或Visual Studio中的工具箱或菜單）提供針對所使用的UI框架定製的體驗。如果應用程式同時使用兩個框架，則兩個屬性都可以設置為true，例如，當Windows窗體對話框承載WPF控制項時。

在接下來的幾個月中，我們將重點關註完成WPF和Windows Forms的開源，使Visual Studio設計人員能夠使用.NET Core，並添加對Windows桌面應用程式中常用的API的支持。請分享您對dotnet / winforms ， dotnet / wpf和dotnet / core repos的反饋。

應用程式現在預設具有可執行文件

.NET Core應用程式現在使用可執行文件構建。這對於使用全局安裝的.NET Core版本的應用程式來說是新的。到目前為止，只有自包含的應用程式具有可執行文件。您可以看到以下示例中生成的可執行文件。

對於這些可執行文件，您可以期望與其他本機可執行文件相同的內容，例如：

• 您可以雙擊可執行文件。
• 您可以在不使用dotnet工具的情況下從命令提示符啟動應用程式，在Windows上使用./myconsole ，在Linux和macOS上使用myconsole.exe ，如以下示例所示。

在Windows上：

 C:Usersrlandermyconsole>dotnet build

C:Usersrlandermyconsole>cd binDebugnetcoreapp3.0

C:UsersrlandermyconsolebinDebugnetcoreapp3.0>dir /b 

myconsole.deps.json

myconsole.dll

myconsole.exe

myconsole.pdb

myconsole.runtimeconfig.dev.json

myconsole.runtimeconfig.json

C:UsersrlandermyconsolebinDebugnetcoreapp3.0>myconsole.exe

Hello World!

C:UsersrlandermyconsolebinDebugnetcoreapp3.0>dotnet myconsole.dll

Hello World! 

在Linux上（和macOS類似）：

 root@cc08212a1da6:/myconsole # dotnet build

root@cc08212a1da6:/myconsole # cd bin/Debug/netcoreapp3.0/

root@cc08212a1da6:/myconsole/bin/Debug/netcoreapp3.0 # ls

myconsole myconsole.dll myconsole.runtimeconfig.dev.json

myconsole.deps.json myconsole.pdb myconsole.runtimeconfig.json

root@cc08212a1da6:/myconsole/bin/Debug/netcoreapp3.0 # ./myconsole

Hello World!

root@cc08212a1da6:/myconsole/bin/Debug/netcoreapp3.0 # dotnet myconsole.dll

Hello World! 

提供的可執行文件與您正在使用的SDK的環境相匹配。我們還沒有為其他運行時環境啟用-r參數。

dotnet build現在複製依賴項

dotnet build現在可以在構建操作期間將NuGet緩存中的NuGet依賴項從NuGet緩存複製到構建輸出文件夾。在此版本之前，這些依賴項僅作為dotnet發佈的一部分進行複製。此更改允許您將構建輸出xcopy到不同的電腦。

有一些操作，如鏈接和剃刀頁面發佈仍然需要發佈。

您可以在以下示例中看到新體驗：

 C:Usersrlandermyconsole>dotnet add package Newtonsoft.json

C:Usersrlandermyconsole>dotnet build

C:Usersrlandermyconsole>dir /b binDebugnetcoreapp3.0*.dll

myconsole.dll

Newtonsoft.Json.dll 

本地dotnet工具

.NET Core工具已更新為包含本地工具方案。我們在.NET Core 2.1中添加了全局工具 。可以從機器上的任何位置為當前用戶提供全局工具。這很好，但是這不允許每個位置選擇版本（通常是每個存儲庫），並且它們不提供簡單的方法來恢復開發或構建工具環境。磁碟上的特定位置現在可以與一組本地工具及其版本相關聯。本地工具依賴於名為dotnet-tools.json的工具清單文件。我們建議在存儲庫的根目錄中提供工具清單文件。

本地工具具有將全局工具添加到工具清單文件（通常是存儲庫）並克隆包含它們的存儲庫的不同體驗。如果克隆包含本地工具的repo，則只需運行以下命令：

 dotnet tool restore 

恢復後，您可以使用以下命令調用本地工具：

 dotnet tool run <toolCommandName> 

調用本地工具時，dotnet會搜索目錄結構的清單。找到工具清單文件後，將搜索所請求的工具。如果找到該工具，它將包含在NuGet全局包位置中查找工具所需的信息。工具清單文件中的工具的正確版本在還原時放置在緩存中。

如果在清單中找到該工具，但在緩存中找不到該工具，則用戶會收到錯誤。預覽1後，該消息將得到改進，以請求用戶運行dotnet tool restore 。

要將本地工具添加到目錄，您需要首先創建工具清單文件。在預覽1之後，我們將提供一種機制來創建工具清單文件，可能是通過dotnet新模板。對於預覽1，您必須使用以下內容創建文件名dotnet-tools.json：

創建清單後，您可以使用以下方法向其添加本地工具：

 dotnet tool install <toolPackageId> 

除非指定了其他版本，否則此命令將安裝最新版本的工具。此版本將寫入工具清單文件，以允許調用正確的工具版本。工具清單文件旨在允許手動編輯 - 您可以執行此操作來更新使用存儲庫所需的版本。示例dotnet-tools.json文件如下：

要從工具清單文件中刪除工具，請運行以下命令：

 dotnet tool uninstall <toolPackageId> 

如果將工具清單文件簽入到源代碼管理中，則克隆代理的程式員可以訪問正確的工具，如上所述。

對於全局和本地工具，都需要相容的運行時版本。目前NuGet.org上的許多工具都面向.NET Core Runtime 2.1。如果只安裝.NET Core 3.0的預覽版，則可能還需要手動安裝.NET Core 2.1 Runtime 。

有關更多信息，請參閱本地工具早期預覽文檔 。

推出快速收件箱JSON閱讀器

System.Text.Json.Utf8JsonReader是一個高性能，低分配，僅向前讀取器，用於UTF-8編碼的JSON文本，從ReadOnlySpan<byte>讀取。 Utf8JsonReader是一種基礎的低級類型，可用於構建自定義解析器和反序列化器。使用新的Utf8JsonReader讀取JSON有效負載比使用Json.NET中的讀取器快2倍。在您需要將JSON令牌實現為（UTF16）字元串之前，它不會分配。

此新API將包含以下組件：

• 預覽1：JSON閱讀器（順序訪問）
• 下一步：JSON編寫器，DOM（隨機訪問），poco序列化器，poco反序列化器

這是Utf8JsonReader的基本讀者迴圈，可以作為起點：

.NET生態系統依賴於Json.NET和其他流行的JSON庫，這些庫仍然是不錯的選擇。 JSON.NET使用.NET字元串作為其基本數據類型，它是引擎蓋下的UTF16。在.NET Core 2.1和3.0中，我們添加了新的API，可以根據使用Span<T>和UTF8字元串編寫需要更少記憶體的JSON API，並更好地滿足Kestrel等高吞吐量應用程式的需求， ASP.NET核心Web伺服器。這就是我們用Utf8JsonReader所做的。

您可能想知道為什麼我們不能只更新Json.NET以包含使用Span<T>解析JSON的支持？ James Newton- King-- Json.NET的作者 - 對此有以下說法：

Json.NET是在10多年前創建的，從那以後它增加了一系列功能，旨在幫助開發人員在.NET中使用JSON。在那個時候，Json.NET也成為了NuGet最依賴和下載的軟體包，並且是.NET中JSON支持的首選庫。不幸的是，Json.NET的豐富功能和受歡迎程度不利於對其進行重大更改。支持像Span這樣的新技術需要對庫進行根本性的重大更改，並且會破壞依賴於它的現有應用程式和庫。

展望未來Json.NET將繼續致力於並投資，既解決了今天的已知問題，也支持未來的新平臺。 Json.NET一直存在於.NET的其他JSON庫中，並且沒有什麼可以阻止您一起使用一個或多個，這取決於您是需要新JSON API的性能還是Json.NET的大型功能集。

有關更多信息，請參閱dotnet / corefx＃33115和System.Text.Json路線圖 。

範圍和指數

我們正在添加一個類型Index ，可用於索引。您可以從一個從頭開始計數的int創建一個，或者從末尾開始計算首碼^運算符：

我們還引入了一個Range類型，它由兩個Index值組成，一個用於開始，一個用於結束，並且可以用x..y範圍表達式編寫。然後，您可以使用Range進行索引以生成切片：

註意：此功能也是C＃8的一部分。

非同步流

我們介紹IAsyncEnumerable<T> ，這正是您所期望的; IEnumerable<T>的非同步版本。該語言允許您等待foreach以消耗它們的元素，並返回它們以生成元素。

以下示例演示了非同步流的生成和使用。 foreach語句是非同步的，它本身使用yield return為調用者生成非同步流。這種模式 - 使用yield return - 是生成非同步流的推薦模型。

除了能夠await foreach ，您還可以創建非同步迭代器，例如，返回IAsyncEnumerable/IAsyncEnumerator的迭代器，您可以await和yield 。對於需要處理的對象，可以使用IAsyncDisposable ，其中包含各種BCL類型實現，例如Stream和Timer 。

註意：此功能也是C＃8的一部分。

System.Buffers.SequenceReader

我們添加了System.Buffers.SequenceReader作為ReadOnlySequence<T>的閱讀器。這允許簡單，高性能，低分配解析可以跨越多個後備緩衝區的System.IO.Pipelines數據。以下示例將輸入Sequence分解為有效的CR / LF分隔行：

Linux上現在支持串列埠API

串口可能看起來像是你多年未在機器上看到的舊外圍設備。它不是筆記本電腦和台式機上常用或可用的埠，但它對物聯網（IoT）解決方案至關重要。我們現在支持Linux上的串列埠。到目前為止，支持僅限於Windows。

在過去的幾個月里，我們一直在與物聯網開發人員討論這種能力。其中一個具體要求是從Raspberry Pi與Arduino進行通信。 以下示例演示了該方案。

我們還致力於使用.NET Core API從Raspberry Pi中刷新Arduino。我們收到了開發人員的要求，他們希望使用RS-485等特定標準以及MODBUS ， CANBUS和ccTalk等協議。請告訴我們您的應用場景需要哪些協議。

現在提供GPIO，PWM，SPI和I2C API

物聯網設備暴露的不僅僅是串列埠。它們通常會暴露多種引腳 ，可以通過編程方式讀取感測器，驅動LED / LCD / eInk顯示器並與我們的設備進行通信。 .NET Core現在具有GPIO ， PWM ， SPI和I²C引腳類型的API。

這些API可通過System.Device.GPIO NuGet包獲得 。 .NET Core 2.1及更高版本將支持它。

上一節顯示了使用引腳8和10（分別為TX和RX）與Arduino進行通信的覆盆子Pi，用於串列埠通信。這是以編程方式編程這些引腳的一個例子。

下圖演示瞭如何將文本列印到LCD面板。

您可以看到使用.NET Core構建物聯網設備的“開發人員安裝”是什麼樣的。

這些包是從dotnet / iot repo構建的。 repo還包括樣本和設備綁定 。我們希望社區將通過提供樣本和設備綁定來加入我們。我們註意到Python社區有一組豐富的樣本和綁定，特別是AdaFruit提供的 。事實上，我們將一些樣本（允許許可證）移植到C＃。我們希望隨著時間的推移為.NET開發人員提供類似的豐富的示例和綁定。

我們的大部分努力都花在支持Raspberry Pi 3中的這些API上。我們計劃支持其他設備，如Hummingboard 。請告訴我們哪些板對您很重要。我們正在Raspberry Pi Zero上測試Mono 。

現在支持Linux上支持TLS 1.3和OpenSSL 1.1.1

.NET Core現在將在OpenSSL 1.1.1中利用TLS 1.3支持 ，當它在給定環境中可用時。根據OpenSSL團隊 ，TLS 1.3有多種好處：

• 由於減少了客戶端和伺服器之間所需的往返次數，縮短了連接時間
• 由於刪除了各種過時和不安全的加密演算法以及更多連接握手的加密，提高了安全性

.NET Core 3.0 Preview 1能夠使用OpenSSL 1.1.1，OpenSSL 1.1.0或OpenSSL 1.0.2（無論在Linux系統上找到的最佳版本）。當OpenSSL 1.1.1可用時，SslStream和HttpClient類型在使用SslProtocols.None（系統預設協議）時將使用TLS 1.3，假設客戶端和伺服器都支持TLS 1.3。

以下示例演示了連接到https://www.cloudflare.com的 Ubuntu 18.10上的.NET Core 3.0 Preview 1：

 jbarton@jsb-ubuntu1810:~/tlstest $ cat Program.cs

using System;

using System.Net.Security;

using System.Net.Sockets;

using System.Threading.Tasks;

namespace tlstest

{

 class Program

 {

 static async Task Main()

 {

 using (TcpClient tcpClient = new TcpClient())

 {

 string targetHost = "www.cloudflare.com";
 await tcpClient.ConnectAsync(targetHost, 443);
 using (SslStream sslStream = new SslStream(tcpClient.GetStream()))

 {

 await sslStream.AuthenticateAsClientAsync(targetHost);
 await Console.Out.WriteLineAsync($"Connected to {targetHost} with {sslStream.SslProtocol}");

 }

 }

 }

 }

}

jbarton@jsb-ubuntu1810:~/tlstest $ dotnet run

Connected to www.cloudflare.com with Tls13

jbarton@jsb-ubuntu1810:~/tlstest $ openssl version

OpenSSL 1.1.1 11 Sep 2018 

註意：Windows和macOS尚不支持TLS 1.3。 .NET Core將在這些操作系統上支持TLS 1.3 - 我們希望在支持可用時自動支持。

加密

我們添加了對AES-GCM和AES-CCM密碼的支持，這些密碼通過System.Security.Cryptography.AesGcm和System.Security.Cryptography.AesCcm 。這些演算法都是帶有關聯數據的身份驗證加密（AEAD）演算法 ，以及添加到.NET Core的第一個經過身份驗證的加密（AE）演算法。

以下代碼演示了使用AesGcm密碼加密和解密隨機數據。 AesCcm的代碼看起來幾乎相同（只有類變數名稱會有所不同）。

 // key should be: pre-known, derived, or transported via another channel, such as RSA encryption

byte [] key = new byte [ 16 ];

RandomNumberGenerator . Fill ( key );

byte [] nonce = new byte [ 12 ];

RandomNumberGenerator . Fill ( nonce );
// normally this would be your data

byte [] dataToEncrypt = new byte [ 1234 ];

byte [] associatedData = new byte [ 333 ];

RandomNumberGenerator . Fill ( dataToEncrypt );

RandomNumberGenerator . Fill ( associatedData );
// these will be filled during the encryption

byte [] tag = new byte [ 16 ];

byte [] ciphertext = new byte [ dataToEncrypt . Length ];
using ( AesGcm aesGcm = new AesGcm ( key ))

{

aesGcm . Encrypt ( nonce , dataToEncrypt , ciphertext , tag , associatedData );

}
// tag, nonce, ciphertext, associatedData should be sent to the other part
byte [] decryptedData = new byte [ ciphertext . Length ];
using ( AesGcm aesGcm = new AesGcm ( key ))

{

aesGcm . Decrypt ( nonce , ciphertext , tag , decryptedData , associatedData );

}
// do something with the data

// this should always print that data is the same

Console . WriteLine ( $" AES-GCM: Decrypted data is{( dataToEncrypt . SequenceEqual ( decryptedData ) ? " the same as " : " different than " )} original data. " );

加密密鑰導入/導出

.NET Core 3.0 Preview 1現在支持從標準格式導入和導出非對稱公鑰和私鑰，而無需使用X.509證書。

所有密鑰類型（RSA，DSA，ECDsa，ECDiffieHellman）都支持公鑰的X.509 SubjectPublicKeyInfo格式，以及私鑰的PKCS＃8 PrivateKeyInfo和PKCS＃8 EncryptedPrivateKeyInfo格式。 RSA還支持PKCS＃1 RSAPublicKey和PKCS＃1 RSAPrivateKey。導出方法都生成DER編碼的二進位數據，導入方法期望相同;如果密鑰以文本友好的PEM格式存儲，則調用者需要在調用導入方法之前對內容進行base64解碼。

 jbarton@jsb-ubuntu1810:~/rsakeyprint $ cat Program.cs

using System;

using System.IO;

using System.Security.Cryptography;

namespace rsakeyprint

{

 class Program

 {

 static void Main(string[] args)

 {

 using (RSA rsa = RSA.Create())

 {

 byte[] keyBytes = File.ReadAllBytes(args[0]);

 rsa.ImportRSAPrivateKey(keyBytes, out int bytesRead);

 

 Console.WriteLine($"Read {bytesRead} bytes, {keyBytes.Length-bytesRead} extra byte(s) in file.");

 RSAParameters rsaParameters = rsa.ExportParameters(true);

 Console.WriteLine(BitConverter.ToString(rsaParameters.D));

 }

 }

 }

}

jbarton@jsb-ubuntu1810:~/rsakeyprint $ echo Making a small key to save on screen space.

Making a small key to save on screen space.

jbarton@jsb-ubuntu1810:~/rsakeyprint $ openssl genrsa 768 | openssl rsa -outform der -out rsa.key

Generating RSA private key, 768 bit long modulus (2 primes)

..+++++++

........+++++++

e is 65537 (0x010001)

writing RSA key

jbarton@jsb-ubuntu1810:~/rsakeyprint $ dotnet run rsa.key

Read 461 bytes, 0 extra byte(s) in file.

0F-D0-82-34-F8-13-38-4A-7F-C7-52-4A-F6-93-F8-FB-6D-98-7A-6A-04-3B-BC-35-8C-7D-AC-A5-A3-6E-AD-C1-66-30-81-2C-2A-DE-DA-60-03-6A-2C-D9-76-15-7F-61-97-57-

79-E1-6E-45-62-C3-83-04-97-CB-32-EF-C5-17-5F-99-60-92-AE-B6-34-6F-30-06-03-AC-BF-15-24-43-84-EB-83-60-EF-4D-3B-BD-D9-5D-56-26-F0-51-CE-F1

jbarton@jsb-ubuntu1810:~/rsakeyprint $ openssl rsa -in rsa.key -inform der -text -noout | grep -A7 private

privateExponent:

 0f:d0:82:34:f8:13:38:4a:7f:c7:52:4a:f6:93:f8:

 fb:6d:98:7a:6a:04:3b:bc:35:8c:7d:ac:a5:a3:6e:

 ad:c1:66:30:81:2c:2a