.NET 6更新使.NET生態系統蛻變
.NET 6 是自.NET 4 框架以來生態系統看到的最大版本更新，雖然.NET Core 是2014年開始非常大的一項重大戰略舉措，但是.NET 6是真正的具有強大動力的非常重要的版本。
2021年11月9日即將正式釋出的.NET 6,也許你認為.NET 5才剛剛釋出，我才剛開始使用.NET Core 3.1,.NET6 就又要釋出了 ，沒錯的，.NET 5是2020年11月10日釋出，.NET Core 3.1早在2019年12月就釋出了，微軟已經承諾了每年都會發佈一個版本的.NET,.NET 6正是按照時間表釋出的版本。和這個版本釋出節奏對應有一個支援政策：https://dotnet.microsoft.com/platform/support/policy/dotnet-core
從.NET 5開始，奇數版本版本18個月修補丁週期，而偶數版本有 三年 的修補丁週期。如果您已經將應用遷移到.NET Core 3.1，請注意，它有一個為期三年的修補丁週期，將於 2022 年 12 月結束;如果您仍在任何之前版本的 .NET Core上，則您目前已不在支援週期內。雖然尚未宣佈對.NET框架 4.6.2 及以後的支援正式結束，但微軟表示，.NET 框架 4.8 是.NET 框架的最後一個主要版本，將會隨Windows 的支援計劃更新：新的功能開發應針對以前稱為 .NET Core（例如.NET 6）的平臺。
.NET 6 帶來了許多效能改進和生產力提升，而且還是一個長期支援版本 。在.NET 的每個連續版本中，.NET 在執行速度和記憶體使用方面都取得了一些令人印象深刻的進步。如果你一直沒有跟蹤， 你很可能會被. NET 框架的累積收益吹走。這一點你可以看看Techempower的測試的報告，具體參見 https://www.techempower.com/benchmarks/
變化很大
我們從 .NET 5開始向前看，作為長期支援 （LTS） 版本，.NET 6 代表著進一步的改進，並具有大量的設計和效能改進。我們將主要看看ASP.NET 6 執行時間的效能改進列表和.NET 6 中的中斷更改，可以看到變化非常大。
C# 語言更新
C#語言的最新版本是10.0，有幾個有趣的變化，對於愛整潔的csharper 來說，全域性引用（Global using）和 檔案範圍的名稱空間 是很好的互補。現在，您可以宣告適用於整個編譯單元（很可能是專案）的全域性使用，並避免到每個檔案頂部的去新增相同指令集。檔案範圍的名稱空間還允許您宣告適用於給定檔案中所有程式碼的名稱空間，無需單行無需更多匹配捲曲大括號，原始檔中的凹痕級別也較少。
以前
CSharp9_Widget.cs
using System;
using System.Collections.Generic;
using System.Linq;
namespace MyNamespace.Data
{
class Widget
{
private List<WidgetPart> _widgetParts;
public IEnumerable<WidgetPart> RequiredParts =>
_widgetParts;
public bool RequiresPart(int partId) =>
_widgetParts.Any(x => x.Id == partId);
}
}
CSharp9_WidgetPartsInventory.cs
using System;
using System.Collections.Generic;
using System.Linq;
namespace MyNamespace.Data
{
class WidgetPartsInventory客棧
{
private Dictionary<int,WidgetPart> _widgetPartsById;
public bool HavePartsToBuildWidget(Widget widget) =>
widget.RequiredParts.All(p =>
_widgetPartsById.ContainsKey(p.Id));
}
}
現在：
CSharp10_GlobalUsing.cs
global using System; global using System.Collections.Generic; global using System.Linq;
CSharp10_Widget.cs
namespace MyNamespace.Data;
class Widget
{
private List<WidgetPart> _widgetParts;
public IEnumerable<WidgetPart> RequiredParts => _widgetParts;
public bool RequiresPart(int partId) =>
_widgetParts.Any(x => x.Id == partId);
}
CSharp10_WidgetPartsInventory.cs
namespace MyNamespace.Data;
class WidgetPartsInventory
{
private Dictionary<int,WidgetPart> _widgetPartsById;
public bool HavePartsToBuildWidget(Widget widget) =>
widget.RequiredParts.All(p =>
_widgetPartsById.ContainsKey(p.Id));
}
還有其他一些與Record、模式和插值字串相關的更新，但這些更新大多是語法糖。
ASP.NET Core 更新
如果你閱讀每個版本的說明，很容易看到 ASP.NET Core 是一個核心，從網路主機和最小 API，熱過載 到blazor都有很多感興趣特性。
網路主機和最小 API
從 ASP.NET Core開始，每個應用程式都將應用初始化程式碼拆分為Program.cs（用於建立 Web 主機）和"Startup.cs（用於配置路由和 IoC 容器配置等應用程式問題）中，通常包含的兩個單獨的Class。特別是Startup類有一種神奇的感覺，它的方法從來沒有被開發人員直接呼叫。而是WebHost在幕後自動呼叫配置方法。
ASP.NET團隊分析了這個設計，並與其他 Web 框架相比，認為設定涉及的東西太多。因此，最小的API概念誕生了。 現在，應用程式初始化可以全部包含在一個檔案中。而且你可能感到奇怪，Main方法都不需要了。可以在應用設定中定義路由，從而大大減少程式碼數量以啟動和執行一個應用程式。
var builder = WebApplication.CreateBuilder(args);
var app = buildePvgLur.Build();
app.MapGet("/",() => "Hello World!");
app.Run();
當然如果你仍然喜歡將服務設定與應用配置分離的組織樣式，你仍然可以為 IServiceCollection 和 IApplicationBuilder 建立擴充套件方法，並從構建器和應用程式物件呼叫它們。
Hot Reload
幾年來，許多 框架都支援熱過載，現在它也成為 C#中 ASP.NET Core應用的標配：通過熱重載入，您可以在應用執行期間（在偵錯程式下）編輯您的 C#程式碼，並且您的程式碼更改將自動反映在您的應用中，而不會丟失應用狀態。換句話說，應用程式不需要重新啟動。對於除錯和互動式開發工作流程來說，這應該是一個很好的改進。 這個功能對於開發來說非常重要，就是這個小功能微軟近日激怒了開源.NET社群，好訊息是微軟聽取了社群的聲音，恢復了通過CLI支援HotReload功能。具體參見 https://www.cnblogs.com/shanyou/p/15450214.html
Blazor
在 ASP.NET Core 6 裡面有大量的更新是關於Blazor。例如，Blazor 應用程式現在可以直接編譯到 WebAssembly，以便在 IL 解釋（即.NET 本地編譯）版本的相同程式碼上來提高應用程式速度。本地編譯/除錯體驗仍然很快，因為漫長的編譯時間僅適用於包裝/釋出。說到效能，Blazor WebAssembly可實現客戶端程式碼的多執行緒。script 受制於瀏覽器中的單執行緒。真正的多執行緒為可以從並行處理中受益的應用程式開闢了一些新的可能性（當然，這取決於瀏覽器的支援）。
還有一個非常有趣的功能，使 Blazor 可用於通過 MAUI 編寫桌面應用程式。 Blazor 的最大好處就是開發人員可以完全用 C# 編寫 Web 應用程式，而不需要為了寫前端必須切換到 Javascript。 如果沒有 C# 和 Javascript 之間的額外接縫，前端和後端程式碼之間就不需要對映層。 可以在兩側使用相同的 C# 模型，這意味著需要的程式碼更少，因此開發應用程式所需的時間也更少。 Blazor 桌面進一步擴充套件了這一概念，以允許此共享程式碼現在也可以與桌面應用程式無縫整合。
MAUI
MAUI 是 Multi-platform App UI 的縮寫，是微軟對跨平臺 UI 框架的下一個嘗試。 MAUI 是 Xamarin 的演進，還包括桌面平臺。 它允許從單個程式碼庫針對 iOS、、macOS 和 Windows。 MAUI 處理對本機平臺 API 的抽象，因此您可以以與平臺無關的方式訪問裝置感測器等內容。 對 Xamarin 的一種印象是，它們最終得到的介面很少，而且在任何平臺上都不太好看。 MAUI 將如何解決這一問題還有待觀察。 如果你http://www.cppcns.com關心的是跨多個平臺的開發速度和維護成本，那麼 MAUI 值得仔細研究。 MAUI 要在2022年的第二個季度正式釋出，建議當前採取觀望的方法，進行小的嘗試以瞭解平臺在全面採用之前的長期發展方向。
以上就是本文的全部內容，希望對大家的學習有所幫助，也希望大家多多支援我們。