.NET 6 預覽版 7 Released

Richard 2021 年 8 月 10 日

我們很高興發布 .NET 6 Preview 7。這是我們進入（兩個）發布候選 (RC) 期之前的最后一次預覽版本。在我們放慢發布速度之前，團隊經常加班夜戰來保證最后一組功能。在這個版本中，您將看到對各種功能的最后一點潤色，以及一次性推出的大型功能。從這一點來看，該團隊將專注于將所有功能實現統一（高）質量，以便 .NET 6 為您的生產工作負載做好準備。

關于生產環境工作負載的話題，值得提醒大家的是，.NET 網站 和 Bing.com 自預覽版 1 以來一直在 .NET 6 上運行。我們正在與各個團隊（Microsoft 和其他團隊）聯系將.NET 6 RC 用于生產。如果您對此感興趣并希望獲得有關如何處理該問題的指導，請聯系 dotnet@microsoft.com，我們總是樂于與早期采用者交流。

您可以下載適用于 Linux、macOS 和 Windows 的.NET 6 Preview 7。

• 安裝程序和二進制文件

• 容器鏡像

• Linux 軟件包

• 發行說明

• API差異

• 已知問題

• GitHub Issue 追蹤

有關客戶端和 Web 應用程序方案新增功能的更多詳細信息，請參閱.NET MAUI和ASP.NET Core。

.NET 6 Preview 7 已經過測試，并且受Visual Studio 2022 Preview 3 支持。Visual Studio 2022 使您能夠利用為 .NET 6 開發的 Visual Studio 工具，例如在 .NET MAUI 中進行開發、C# 應用程序的熱重載、WebForms 的新 Web 實時預覽以及 IDE 體驗中的其他性能改進。Visual Studio Code也支持 .NET 6 。Visual Studio Code的 C# 擴展的最新版本已針對 .NET 6 Preview 7 進行了更新，并且包括對 C# 10 的支持。

查看新的對話帖子，就最新的 .NET 功能進行工程師對工程師的深入討論。我們還發布了有關 C# 10 中的字符串插值和 .NET 6 中的 .NET 6 預覽功能 – 通用數學的文章。

.NET SDK：現代化的 C# 項目模板

我們更新了 .NET SDK 模板以使用最新的 C# 語言功能和模式。我們已經有一段時間沒有在新的語言功能方面重新審視模板了。是時候這樣做了，我們將確保模板在未來使用新的和現代的功能。

新模板中使用了以下語言功能：

• 頂級語句

• 異步 Main 方法

• 全局 using 指令（通過 SDK 驅動的默認值）

• 文件范圍的命名空間

• 目標類型的新表達式

• 可空引用類型

您可能想知道為什么我們通過模板啟用某些功能，而不是在項目面向 .NET 6 時默認啟用它們。您需要做一些工作來將應用程序升級到新版本的 .NET, 作為用于權衡改進平臺的默認行為，這使我們可以改進產品，而不會隨著時間的推移使項目文件復雜化。但是，該模型的某些功能可能會具有破壞性，例如可為空的引用類型。我們不想將這些功能與升級體驗聯系起來，但希望將選擇權留給您，無論何時何地。模板是一個風險低得多的樞軸點，我們可以在那里為新代碼通過項目模板啟用這些功能，設置新的“良好默認模型”，而幾乎沒有下游后果。

控制臺模板

Console模板演示了最大的變化。憑借頂級語句和全局 using 指令，它現在（有效的代碼）是只有一行的。

//?See?https://aka.ms/new-console-template?for?more?information Console.WriteLine("Hello,?World!");

同一模板的 .NET 5 版本包括幾行熟悉的樣式，新的模板只需要一行代碼就可以提供以前實際代碼所需的結構。

using?System;namespace?Company.ConsoleApplication1 {class?Program{static?void?Main(string[]?args){Console.WriteLine("Hello,?World!");}} }

console模板的項目文件也已更改，以啟用可空引用類型功能，如下例所示

<Project?Sdk="Microsoft.NET.Sdk"><PropertyGroup><OutputType>Exe</OutputType><TargetFramework>net6.0</TargetFramework><Nullable>enable</Nullable></PropertyGroup></Project>

其他模板也支持可空性、隱式全局使用和文件范圍的命名空間，包括 ASP.NET Core 和類庫。

ASP.NET Web 模板

web模板也同樣在使用相同的功能來減少代碼行

var?builder?=?WebApplication.CreateBuilder(args); var?app?=?builder.Build();if?(app.Environment.IsDevelopment()) {app.UseDeveloperExceptionPage(); }app.MapGet("/",?()?=>?"Hello?World!");app.Run();

ASP.NET MVC 模板

mvc模板在結構上相似。在本例中，我們已將Program.cs和Startup.cs合并到一個文件 ( Program.cs) 中，從而進一步簡化。

var?builder?=?WebApplication.CreateBuilder(args);//?Add?services?to?the?container. builder.Services.AddControllersWithViews();var?app?=?builder.Build();//?Configure?the?HTTP?request?pipeline. if?(app.Environment.IsDevelopment()) {app.UseDeveloperExceptionPage(); } else {app.UseExceptionHandler("/Home/Error");//?The?default?HSTS?value?is?30?days.?You?may?want?to?change?this?for?production?scenarios,?see?https://aka.ms/aspnetcore-hsts.app.UseHsts(); }app.UseHttpsRedirection(); app.UseStaticFiles();app.UseRouting();app.UseAuthorization();app.MapControllerRoute(name:?"default",pattern:?"{controller=Home}/{action=Index}/{id?}");app.Run();

模板兼容性

有關使用新模板的兼容性問題，請參閱以下文檔。

• 早期 .NET 版本不支持模板中的 C# 代碼

• 隱式命名空間導入

庫：用于可空性信息的反射 API

可空引用類型是編寫可靠代碼的重要特性。它非常適合編寫代碼，但不適用于（直到現在）反射檢查它。新的反射 API使您能夠確定給定方法的參數和返回值的可空性性質。例如，這些新的 API 對基于反射的工具和序列化程序至關重要。

對于上下文，我們在 .NET 5 中向 .NET 庫添加了可為空的注釋（并在 .NET 6 中完成），并且正在對本版本的ASP.NET Core做同樣的事情。我們還看到開發人員為他們的項目采用可空引用類型。

可空性信息使用自定義屬性保存在元數據中。原則上，任何人都可以讀取自定義屬性，但是，這并不理想，因為使用編碼是很重要的。

以下示例演示了將新 API 用于幾個不同的場景。

獲取頂級可空性信息

假設您正在實現一個序列化程序。使用這些新的 API，序列化程序可以檢查給定的屬性是否可以設置為null：

private?NullabilityInfoContext?_nullabilityContext?=?new?NullabilityInfoContext();private?void?DeserializePropertyValue(PropertyInfo?p,?object?instance,?object??value) {if?(value?is?null){var?nullabilityInfo?=?_nullabilityContext.Create(p);if?(nullabilityInfo.WriteState?is?not?NullabilityState.Nullable){throw?new?MySerializerException($"Property?'{p.GetType().Name}.{p.Name}''?cannot?be?set?to?null.");}}p.SetValue(instance,?value); }

獲取嵌套的可空性信息

可空性對可以（正式地）保存其他對象（如數組和元組）的對象進行了特殊處理。例如，您可以指定數組對象（作為變量，或作為類型成員簽名的一部分）必須為非空，但元素可以為空，反之亦然。使用新的反射 API 可以檢查這種額外級別的特異性，如以下示例所示。

class?Data {public?string?[]?ArrayField;public?(string?,?object)?TupleField; } private?void?Print() {Type?type?=?typeof(Data);FieldInfo?arrayField?=?type.GetField("ArrayField");FieldInfo?tupleField?=?type.GetField("TupleField");NullabilityInfoContext?context?=?new?();NullabilityInfo?arrayInfo?=?context.Create(arrayField);Console.WriteLine(arrayInfo.ReadState);????????//?NotNullConsole.WriteLine(arrayInfo.Element.State);????//?NullableNullabilityInfo?tupleInfo?=?context.Create(tupleField);Console.WriteLine(tupleInfo.ReadState);??????????????????????//?NotNullConsole.WriteLine(tupleInfo.GenericTypeArguments?[0].State);?//?NullableConsole.WriteLine(tupleInfo.GenericTypeArguments?[1].State);?//?NotNull }

庫：ZipFile 遵循 Unix 文件權限

System.IO.Compression.ZipFile 類型現在在類Unix操作系統讀取 zip 文件時，在創建和設置文件權限期間會捕獲 Unix 文件權限，此更改允許通過 zip 文件來回傳送可執行文件，這意味著您不再需要在解壓縮 zip 存檔后修改文件權限以使文件可執行。這也遵循了讀/寫權限，以及user/group/other 權限。

如果 zip 文檔不包含文件權限（因為它是在 Windows 上創建的，或者使用未捕獲權限的工具，如 .NET 的早期版本），則提取的文件將獲得默認文件權限，就像任何其他文件一樣新創建的文件。

Unix 文件權限也適用于其他 zip 存檔工具，包括：

• Info-ZIP

• 7-Zip

.NET 7 早期功能預覽：通用數學

對于 .NET 6，我們已經構建了將 API 標記為“預覽中”的功能。這種新方法將使我們能夠跨多個主要版本提供和使用預覽功能。為了使用預覽 API，項目需要明確選擇使用預覽功能。如果您在未明確選擇的情況下使用預覽功能，您將看到帶有可操作消息的構建錯誤，從 .NET 6 RC1 開始。在以后的版本中，預覽功能可能會以破壞性的方式發生變化。這就是讓他們加入的原因。

我們在 .NET 6 中預覽的其中一項功能是靜態抽象接口成員。這些允許您在接口中定義靜態抽象方法（包括運算符）。例如，現在可以實現代數泛型方法。對于某些人來說，此功能將是我們今年提供的絕對出色的改進，這可能會使Span<T> 之后的最重要的新的類型系統功能。

以下示例使用了一個 IEnumerable<T> 對象并且由于 T被限制為INumber<T>, 可能是INumber<int>，因此能夠對所有值求和

public?static?T?Sum<T>(IEnumerable<T>?values)where?T?:?INumber<T> {T?result?=?T.Zero;foreach?(var?value?in?values){result?+=?value;}return?result; }

這是有效的，因為 INumber<T> 定義了接口實現者必須滿足的各種（靜態）運算符重載。IAdditionOperators 也許是最簡單的新接口來理解，這本身是從INumber 繼承的。

這一切都由允許在接口中聲明static abstract成員的新功能提供支持。這使接口能夠公開運算符和其他靜態方法，例如Parse或Create，以及由派生類型實現的那些。請參閱我們相關的博客文章了解更多詳情！

這里提到的所有功能都是 .NET 6 的預覽功能，不支持在生產中使用。我們將不勝感激您使用它們的反饋。我們打算在 .NET 7 中繼續發展和改進通用數學功能以及支持它們的運行時和 C# 功能。我們希望對當前體驗進行重大更改，這也是新 API 被標記為”在預覽中”的部分原因。

庫：NativeMemory API

我們增加了新的本機內存分配的API通過System.Runtime.InteropServices.NativeMemory暴露。這些 API 代表了malloc、free、realloc和calloc C API 的等價物，還包括用于進行對齊分配的 API。

您可能想知道如何考慮這些 API。首先，它們是用于底層代碼和算法的低級 API。應用程序開發人員很少會使用這些。考慮這些 API 的另一種方式類似于平臺內在API，它們是用于芯片指令的低級 .NET API。這些 API 很相似，但為與內存相關的操作公開了低級 API。

庫：System.Text.Json 序列化通知

System.Text.Json 序列化程序現在將通知作為（反）序列化操作的一部分公開。它們對于默認值和驗證很有用。要使用它們，實現一個或多個接口IJsonOnDeserialized，IJsonOnDeserializing，IJsonOnSerialized或IJsonOnSerializing在 System.Text.Json.Serialization 命名空間下。

這是一個在JsonSerializer.Serialize() 和 JsonSerializer.Deserialize() 兩者期間都進行驗證并確保屬性FirstName不是null的示例。

??public?class?Person?:?IJsonOnDeserialized,?IJsonOnSerializing{public?string?FirstName{?get;?set;?}void?IJsonOnDeserialized.OnDeserialized()?=>?Validate();?//?Call?after?deserializationvoid?IJsonOnSerializing.OnSerializing()?=>?Validate();?//?Call?before?serializationprivate?void?Validate(){if?(FirstName?is?null){throw?new?InvalidOperationException("The?'FirstName'?property?cannot?be?'null'.");}}}

在以前，您需要實現自定義轉換器才能實現此功能。

庫：System.Text.Json 序列化屬性排序

我們還添加了控制屬性序列化順序的功能，使用 System.Text.Json.Serialization.JsonPropertyOrderAttribute. 一個整數指定順序。較小的整數首先被序列化；沒有屬性的屬性的默認排序值為 0。

這是一個指定 JSON 應按順序序列化的示例：Id, City, FirstName, LastName

public?class?Person {public?string?City?{?get;?set;?}?//?No?order?defined?(has?the?default?ordering?value?of?0)[JsonPropertyOrder(1)]?//?Serialize?after?other?properties?that?have?default?orderingpublic?string?FirstName?{?get;?set;?}[JsonPropertyOrder(2)]?//?Serialize?after?FirstNamepublic?string?LastName?{?get;?set;?}[JsonPropertyOrder(-1)]?//?Serialize?before?other?properties?that?have?default?orderingpublic?int?Id?{?get;?set;?} }

以前，序列化順序是由反射順序決定的，它既不是確定性的，也不是導致特定的所需順序。

庫：使用 System.Text.Json.Utf8JsonWriter“編寫原始”JSON

在使用 Utf8JsonWriter編寫 JSON 有效負載時，有時您需要集成“原始”JSON。

例如：

• 我有一個有意在網絡上寫出的字節序列，并且我知道我在做什么（如下例所示）。

• 我有一個 blob，我認為它代表 JSON 內容并且我想將其封裝起來，我需要確保信封及其內部內容保持格式正確

JsonWriterOptions?writerOptions?=?new()?{?WriteIndented?=?true,?};using?MemoryStream?ms?=?new(); using?UtfJsonWriter?writer?=?new(ms,?writerOptions);writer.WriteStartObject(); writer.WriteString("dataType",?"CalculationResults");writer.WriteStartArray("data");foreach?(CalculationResult?result?in?results) {writer.WriteStartObject();writer.WriteString("measurement",?result.Measurement);writer.WritePropertyName("value");//?Write?raw?JSON?numeric?value?using?FormatNumberValue?(not?defined?in?the?example)byte[]?formattedValue?=?FormatNumberValue(result.Value);writer.WriteRawValue(formattedValue,?skipValidation:?true);writer.WriteEndObject(); }writer.WriteEndArray(); writer.WriteEndObject();

下面是對上面代碼——特別是FormatNumberValue——正在做什么的描述。為了性能，System.Text.Json當數字為整數時省略小數點/值，例如1.0. 基本原理是寫入更少的字節有利于性能。在某些情況下，保留十進制值可能很重要，因為消費者將沒有小數的數字視為整數，否則視為雙精度數。這種新的“原始值”模型使您可以隨時隨地進行控制。

庫：同步流重載 JsonSerializer

我們添加了新的同步 API，JsonSerializer用于在流中序列化和反序列化 JSON 數據。您可以在以下示例中看到這一點。

using?MemoryStream?ms?=?GetMyStream(); MyPoco?poco?=?JsonSerializer.Deserialize<MyPoco>(ms);

這些新的同步 API 包括通過接受JsonTypeInfo<T>或JsonSerializerContext實例與新的System.Text.Json 源生成器兼容和可用的重載。

庫：刪除了System.Text.Json.Nodes.JsonNode 對 dynamic 的支持

JsonSerializer 中對 C# dynamic 類型的支持已被刪除。我們dynamic在預覽版 4 中添加了支持，但后來決定是一個糟糕的設計選擇，包括使其成為JsonNode類型的必需依賴項。

此更改被認為是從 .NET 6 一個預覽到另一個預覽的重大更改，但不是從 .NET 5 到 6。

庫：System.Diagnostics Propagators

在過去幾年中，我們一直在改進對OpenTelemetry 的支持。實現強大支持的關鍵方面之一是確保需要參與遙測生產的所有組件以正確的格式生成網絡標頭。這真的很難做到，尤其是隨著 OpenTelemetry 規范的變化。OpenTelemetry 定義了傳播概念來幫助解決這種情況。我們正在采用傳播來啟用標頭自定義的通用模型。

更廣泛概念的背景：

• OpenTelemetry規范——分布式跟蹤數據結構的內存表示。

• OpenTelemetry Span — 用于跟蹤的構建塊，由.NET 中的System.Diagnostics.Activity表示。

• W3C TraceContext — 關于如何通過眾所周知的 HTTP 標頭傳播這些分布式跟蹤數據結構的規范。

以下代碼演示了使用傳播的一般方法。

DistributedContextPropagator?propagator?=?DistributedContextPropagator.Current; propagator.Inject(activity,?carrier,?(object?theCarrier,?string?fieldName,?string?value)?=> {//?Extract?the?context?from?the?activity?then?inject?it?to?the?carrier. });

您還可以選擇使用不同的傳播器。

//?Set?the?current?propagation?behavior?to?not?transmit?any?distributed?context?information?in?outbound?network?messages. DistributedContextPropagator.Current?=?DistributedContextPropagator.CreateNoOutputPropagator();

該DistributedContextPropagator抽象類確定是否和如何分配的上下文信息進行編碼和解碼，因為它穿過網絡。編碼可以通過任何支持鍵值字符串對的網絡協議傳輸。DistributedContextPropagator將值注入到載體中并從載體中提取值作為鍵/值字符串對。通過添加對傳播器的支持，我們啟用了兩件事：

• 您不再需要使用W3C TraceContext標頭。您可以編寫自定義傳播器（即，使用您自己的標頭名稱，包括根本不發送它們），而無需庫 HttpClient、ASP.NET Core 具有此自定義格式的先驗知識

• 如果您使用自定義傳輸（例如，消息隊列）實現庫，則現在可以支持各種有線格式，只要您支持發送和接收文本映射（例如）Dictionary<string, string>

大多數應用程序代碼不需要直接使用此功能，但是，如果您使用 OpenTelemetry，您很可能會在調用堆棧中看到它。如果關心跟蹤和因果關系，一些庫代碼將可能參與此模型。

庫：加密操作的簡化調用模式

.NET 加密和解密例程是圍繞流設計的，沒有定義有效負載何時已經在內存中的真正概念。新的 Encrypt- 和 Decrypt- 方法SymmetricAlgorithm加速了內存中已經存在的情況，旨在為調用者和代碼審查者提供清晰的信息。此外，它們支持從跨度讀取和向跨度寫入。

新的簡化方法提供了一種使用加密 API 的直接方法：

private?static?byte[]?Decrypt(byte[]?key,?byte[]?iv,?byte[]?ciphertext) {using?(Aes?aes?=?Aes.Create()){aes.Key?=?key;return?aes.DecryptCbc(ciphertext,?iv);} }

使用新的 Encrypt- 和 Decrypt- 方法，僅使用來自 SymmetricAlgorithm 實例的 key 屬性。新的 DecryptCbc 方法支持選擇填充算法，但 PKCS#7 經常與 CBC 一起使用，因此它是默認參數。如果您喜歡清晰模式，只需指定它：

private?static?byte[]?Decrypt(byte[]?key,?byte[]?iv,?byte[]?ciphertext) {using?(Aes?aes?=?Aes.Create()){aes.Key?=?key;return?aes.DecryptCbc(ciphertext,?iv,?PaddingMode.PKCS7);} }

您可以看到現有模式（使用 .NET 5）需要更多的管道才能獲得相同的結果。

private?static?byte[]?Decrypt(byte[]?key,?byte[]?iv,?byte[]?ciphertext) {using?(Aes?aes?=?Aes.Create()){aes.Key?=?key;aes.IV?=?iv;//?These?are?the?defaults,?but?let's?set?them?anyways.aes.Padding?=?PaddingMode.PKCS7;aes.Mode?=?CipherMode.CBC;using?(MemoryStream?destination?=?new?MemoryStream())using?(ICryptoTransform?transform?=?aes.CreateDecryptor())using?(CryptoStream?cryptoStream?=?new?CryptoStream(destination,?transform,?CryptoStreamMode.Write)){cryptoStream.Write(ciphertext,?0,?ciphertext.Length);cryptoStream.FlushFinalBlock();return?destination.ToArray();}} }

庫：全球化不變模式下的完整案例映射支持

全球化不變模式使您能夠消除應用程序對全球化數據和行為的依賴，以換取較小的應用程序（主要在 Linux 上）。我們改進了全球化不變模式以支持完整 Unicode 字符集的大小寫映射。運營之前，該模式只支持ASCII字符范圍比如 String.ToUpper，String.ToLower和字符串比較，并與搜索IGNORECASE選項。

基于 Alpine 的 .NET 容器鏡像是我們默認啟用全球化環境模式的唯一環境。

運行時：W^X支持所有平臺和架構

運行時現在有一種模式，在這種模式下，它不會同時創建或使用任何可寫和可執行的內存頁。所有可執行內存都映射為只讀。此功能已在 macOS（適用于 Apple Silicon）上啟用。在 Apple Silicon 機器上，同時可寫和可執行的內存映射是被禁止的。

此功能現已在所有其他平臺上啟用和支持，作為可選體驗。在這些平臺上，可執行代碼的生成/修改是通過單獨的讀寫內存映射完成的。這對于 JIT 代碼和運行時生成的幫助程序都是正確的。這些映射是在與可執行代碼地址不同的虛擬內存地址處創建的，并且僅在執行寫入時存在很短的時間。例如，JIT 現在將代碼生成到暫存緩沖區中，在整個方法被 JIT 之后，使用單個內存復制函數調用將代碼復制到可執行內存中。并且可寫映射生命周期僅跨越內存復制的時間。

可以通過將環境變量設置DOTNET_EnableWriteXorExecute為1. 此功能在 .NET 6 中是可選的，因為它具有啟動回歸（Apple Silicon 除外）。在我們的 ASP.Net 基準測試中，當使用 Ready To Run (R2R) 編譯時，回歸約為 10%。但是，在啟用和不啟用該功能的情況下，測量的穩態性能相同。對于啟動性能不重要的應用程序，我們建議啟用此功能以提高其提供的安全性。我們打算在 .NET 7 中解決性能回歸問題，并在那時默認啟用該功能。

運行時：CodeGen 變更日志

在預覽版 7 中的代碼生成中進行了以下更改。

社區 PR

以下 PR 均來自@SingleAccrtion：

• 優化 32 位目標 runtime#53040CAST(int <- long)

• 消除對小類型的鏈式轉換 runtime#52561

• 從除法變形中刪除一些不需要的代碼 runtime#53464

• 修復長 muls 變形中的 CQ 回歸和正確性錯誤 runtime#53566

• 優化窄存儲不要消除 FP 類型的強制轉換 runtime#53667

• 移動“不要零擴展 setcc”優化以降低 runtime#53778

• 禁用實現定義的強制轉換的折疊 runtime#53782

• 為 VNF_MapStore 和 VNF_MapSelect 添加 args 描述 runtime#54108

• 導入cgt.un(op, 0)為NE(op, 0) runtime#54539

• 使用本地斷言道具在返回省略強制轉換 runtime#55632

動態 PGO

以下 PR 支持動態 PGO 項目。

• [JIT] 改進 inliner：新啟發式，依賴 PGO 數據 runtime#52708

• 內聯：擴展配置調用站點的 IL 限制，允許內聯交換機。runtime#55478

• JIT：靜態類推導失敗時啟用GDV。runtime#55660

LSRA

以下 PR 支持LRSA 項目。

• 在定義時溢出單定義變量以避免進一步溢出 runtime#54345

• 在 minopts 中將 vars 標記為 do not enreg。runtime#54998

循環優化

以下 PR 改進了循環優化。

• 改進循環克隆，調試改進 runtime#55299

• 支持使用結構索引表達式的數組克隆循環 runtime#55612

• 將 RyuJIT 優化的最大循環從 16 增加到 64。runtime#55614

結構

以下 PR 改進了結構處理。

• 在 win x64 上注冊結構體。runtime#55045

• Enreg Windows x86 struct。runtime#55535

• 在所有平臺上默認啟用 StructEnreg。runtime#55558

• 改進 TryTransformStoreObjAsStoreInd 優化。runtime#55727

優化

以下 PR 提供了一般優化。

• 布爾邏輯中的“==0”優化 #13573 runtime#49548

• 尾調用時允許隱式擴展runtime#54864

貢獻者展示

我們即將——正如多次提到的那樣——發布到最后。我們想花點時間展示一些做出重大貢獻的社區貢獻者。有很多人做出了重大貢獻。以下人員是從團隊中的一些人中被提名參加這次展示的。如果人們喜歡，我們可以繼續這個展示部分。

文本是用貢獻者自己的話寫的。

Andrii Kurdiumov (@kant2002)

我是 Andrii Kurdiumov，住在哈薩克斯坦的阿拉木圖。通過貿易，我致力于在企業中構建新產品。

我決定為 .NET 做出貢獻，因為我看到了利用新的 MS 技術進入新市場的機會。Blazor WebAssembly 和 .NET on Raspberry 運行良好，但我擔心這些技術會在極端或不尋常的要求下崩潰。所以我決定花一點時間來看看 NativeAOT 是否可以幫助我。到目前為止，我的貢獻主要集中在 NativeAOT 項目上，甚至是 WinForms 項目。有一段時間我計劃遵循這個方向。

這些就是我開始貢獻的原因。我繼續貢獻的原因如下：我不斷感受到 .NET 工作人員的支持，我知道他們在軟件開發的廣闊領域擁有豐富的經驗。圍繞 .NET 工作的人們非常關心高質量標準，這立即為周圍的任何人定下了基調。我個人喜歡這種環境。

SingleAccretion

我是一個有抱負的年輕程序員，出人意料地來自俄羅斯。作為一個編寫代碼的人，我從 .NET 開始，逐漸從技術棧的較高層轉到較低層，最終在編譯器上工作，就在虛擬機的空白邊緣:), . 這是一種相當迷人的活動，了解與 RyuJit 一樣復雜和古老的系統，但這也是它獨特的吸引力，我想，至少對于像我這樣好奇的人來說。

然而，這不是我為 .NET 做出貢獻的原因，畢竟我可以開始自己的分支。我認為可以公平地說，在這幾個月里涉足了如此多的 GH 線程，在任何地方都無法看到人們對我們領域的問題有如此深刻和豐富的理解。成為這個社區的一員，并且能夠對其中的問題進行推理，這是我真正珍惜的東西。

結語

我們正處于發行版的新時期，我們認為新功能和改進已經完成。干得漂亮，團隊。這是另一季 .NET 預覽的結束。

我們繼續希望得到并依賴您的反饋。我們將把 .NET 6 的其余部分集中在回歸（功能和性能）和新功能中發現的錯誤上。在大多數情況下，功能改進需要等待 .NET 7。請分享您的任何和所有反饋，我們很樂意對其進行分類。

感謝所有為 .NET 6 成為另一個偉大版本做出貢獻的人。

感謝您成為 .NET 開發人員。

總結

以上是生活随笔為你收集整理的.NET 6 预览版 7 Released的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。