原文來自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🇩🇪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
可以使用System.Security.Cryptography.Pkcs.Pkcs8PrivateKeyInfo類檢查PKCS＃8文件。
可以分別使用System.Security.Cryptography.Pkcs.Pkcs12Info和System.Security.Cryptography.Pkcs.Pkcs12Builder檢查和操作PFX / PKCS＃12文件。
更多BCL改進
我們優化了Span<T> ， Memory<T>以及.NET Core 2.1中引入的相關類型。跨度構造，切片，解析和格式化等常用操作現在表現更好。此外，像String這樣的類型在使用Dictionary<TKey, TValue>和其他集合作為鍵時，已經看到了封底改進，使它們更有效。無需更改代碼即可享受這些改進。
以下改進也是.NET Core 3 Preview 1中的新增功能：
- Brotli支持內置於HttpClient
- ThreadPool.UnsafeQueueWorkItem（IThreadPoolWorkItem）
- Unsafe.Unbox
- CancellationToken.Unregister
- 復雜算術運算符
- TCP的套接字API保持活躍
- StringBuilder.GetChunks
- IPEndPoint解析
- RandomNumberGenerator.GetInt32
接口成員的默認實現
今天，一旦你發布了一個界面游戲結束：你不能在不破壞它的所有現有實施者的情況下添加成員。
在C＃8.0中，我們讓您為接口成員提供一個主體。因此，如果有人沒有實現該成員（可能因為它們在編寫代碼時尚未實現），他們只會獲得默認實現。
在這個例子中。 ConsoleLogger類不必實現ILogger的Log（Exception）重載，因為它是使用默認實現聲明的。現在，只要為現有實現者提供默認實現，就可以向現有公共接口添加新成員。
分層編譯
默認情況下，使用.NET Core 3.0打開分層編譯 。它是一項功能，使運行時能夠更自適應地使用實時（JIT）編譯器，以在啟動時獲得更好的性能並最大化吞吐量。它作為.NET Core 2.1中的選擇加入功能添加，然后在.NET Core 2.2 Preview 2中默認啟用。我們決定在最終的.NET Core 2.2版本中默認啟用它，因此將其切換回選擇加入，就像.NET Core 2.1一樣。它在.NET Core 3.0中默認啟用，我們希望它保留在該配置中。
使用MetadataLoadContext進行匯編元數據讀取
我們添加了新的MetadataLoadContext類型，該類型可以在不影響調用者應用程序域的情況下讀取程序集元數據。程序集作為數據讀取，包括為不同的體系結構和平台構建的程序集，而不是當前的運行時環境。 MetadataLoadContext與ReflectionOnlyLoad類型重疊，后者僅在.NET Framework中可用。
System.Reflection.MetadataLoadContext包中提供了MetdataLoadContext。它是.NET Standard 2.0軟件包。
MetadataLoadContext公開類似於AssemblyLoadContext類型的API，但不基於該類型。與AssemblyLoadContext非常相似，MetadataLoadContext允許在隔離的程序集加載Universe中加載程序集。 MetdataLoadContext API返回Assembly對象，允許使用熟悉的反射API。不允許使用面向執行的API，例如MethodBase.Invoke ，並將拋出InvalidOperationException。
以下示例演示如何在實現給定接口的程序集中查找具體類型：
MetadataLoadContext的方案包括設計時功能，構建時工具和運行時點亮功能，這些功能需要將一組程序集作為數據進行檢查，並在執行檢查后釋放所有文件鎖和內存。
MetadataLoadContext具有傳遞給其構造函數的解析程序類。解析器的工作是根據AssemblyName加載程序集。解析器類派生自抽象的MetadataAssemblyResolver類。 PathAssemblyResolver提供了基於路徑的方案的解析器的實現。
MetadataLoadContext測試演示了許多用例。 大會測試是一個很好的起點。
注意：以下（現在很古老的）關於.NET程序集元數據的文章將從這個新API中受益： 使用MetaViewer在.NET EXE中顯示元數據 。
ARM64
我們正在為此版本添加對ARM64 for Linux的支持。對於上下文，我們添加了對帶有.NET Core 2.1的Linux的ARM32和帶有.NET Core 2.2的Windows的支持。 ARM64的主要用例目前是IoT方案。我們正在使用的一些開發人員希望在ARM32環境和ARM64上的其他環境中部署。
Alpine，Debian和Ubuntu Docker鏡像可用於.NET Core for ARM64 。
有關更多信息，請查看.NET Core ARM64狀態 。
平台支持
以下操作系統將支持.NET Core 3：
- Windows客戶端：7,8.1,10（1607+）
- Windows Server：20012 R2 SP1 +
- macOS：10.12+
- RHEL：6+
- Fedora：26歲以上
- Ubuntu：16.04+
- Debian：9+
- SLES：12+
- openSUSE：42.3+
- 高山：3.8+
芯片支持如下：
- Windows，macOS和Linux上的x64
- Windows上的x86
- Windows上的ARM32（附帶預覽版2）和Linux
- Linux上的ARM64
對於Linux，Debian 9+和Ubuntu 16.04+支持ARM32。對於ARM64，增加Alpine 3.8也是如此。這些是與X64支持的發行版相同的版本。我們有意識地決定在X64，ARM32和ARM64之間使支持的平台盡可能相似。
Docker Hub上的microsoft / dotnet提供了.NET Core 3.0的Docker鏡像，包括ARM64。
摘要
我們很高興能夠在今天推出.NET Core 3的第一個預覽版！ .NET Core 3 Preview 1還包含.NET Core 2.2中的功能。您可以在此處閱讀有關各種組件的更多信息：
我們將在未來幾周內發布更多關於.NET Core 3的詳細帖子，其中還將包括.NET Standard 2.1的更新，但尚未進入預覽1。
要知道，如果您有現有的.NET Framework應用程序，那么就沒有壓力將它們移植到.NET Core。我們將向.NET Framework 4.8添加功能以支持新的桌面方案。雖然我們建議新的桌面應用程序應考慮針對.NET Core，但.NET Framework將保留高兼容性欄，並將在很長一段時間內為您的應用程序提供支持。使用.NET Core 3，我們將為希望利用.NET Core中的最新功能的應用程序提供出色的體驗。