.NET 6 是自.NET 4 框架以來生態(tài)系統(tǒng)看到的最大版本更新，雖然.NET Core 是2014年開始非常大的一項重大戰(zhàn)略舉措，但是.NET 6是真正的具有強大動力的非常重要的版本。

2021年11月9日即將正式發(fā)布的.NET 6, 也許你認為.NET 5才剛剛發(fā)布，我才剛開始使用.NET Core 3.1, .NET6 就又要發(fā)布了 ，沒錯的，.NET 5是2020年11月10日發(fā)布，.NET Core 3.1早在2019年12月就發(fā)布了，微軟已經(jīng)承諾了每年都會發(fā)布一個版本的.NET , .NET 6正是按照時間表發(fā)布的版本。和這個版本發(fā)布節(jié)奏對應有一個支持政策：https://dotnet.microsoft.com/platform/support/policy/dotnet-core

從.NET 5開始，奇數(shù)版本版本18個月修補丁周期，而偶數(shù)版本有 三年 的修補丁周期。如果您已經(jīng)將應用遷移到.NET Core 3.1，請注意，它有一個為期三年的修補丁周期，將于 2022 年 12 月結束;如果您仍在任何之前版本的 .NET Core上，則您目前已不在支持周期內(nèi)。雖然尚未宣布對.NET框架 4.6.2 及以后的支持正式結束，但微軟表示，.NET 框架 4.8 是.NET 框架的最后一個主要版本，將會隨Windows 的支持計劃更新：新的功能開發(fā)應針對以前稱為 .NET Core（例如.NET 6）的平臺。

.NET 6 帶來了許多性能改進和生產(chǎn)力提升，而且還是一個長期支持版本 。在.NET 的每個連續(xù)版本中，.NET 在執(zhí)行速度和內(nèi)存使用方面都取得了一些令人印象深刻的進步。如果你一直沒有跟蹤， 你很可能會被. NET 框架的累積收益吹走。這一點你可以看看Techempower的測試的報告，具體參見 https://www.techempower.com/benchmarks/

變化很大

我們從 .NET 5開始向前看，作為長期支持 （LTS） 版本，.NET 6 代表著進一步的改進，并具有大量的設計和性能改進。我們將主要看看ASP.NET 6 運行時間的性能改進列表和.NET 6 中的中斷更改，可以看到變化非常大。

C# 語言更新

C#語言的最新版本是10.0，有幾個有趣的變化，對于愛整潔的csharper 來說，全局引用（Global using）和 文件范圍的命名空間 是很好的互補。現(xiàn)在，您可以聲明適用于整個編譯單元（很可能是項目）的全局使用，并避免到每個文件頂部的去添加相同指令集。文件范圍的命名空間還允許您聲明適用于給定文件中所有代碼的命名空間，無需單行無需更多匹配卷曲大括號，源文件中的凹痕級別也較少。

以前

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));
	}
}

現(xiàn)在：

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 是一個核心，從網(wǎng)絡主機和最小 API，熱重載 到blazor都有很多感興趣特性。

網(wǎng)絡主機和最小 API

從 ASP.NET Core開始，每個應用程序都將應用初始化代碼拆分為Program.cs（用于創(chuàng)建 Web 主機）和"Startup.cs（用于配置路由和 IoC 容器配置等應用程序問題）中，通常包含的兩個單獨的Class。特別是Startup類有一種神奇的感覺，它的方法從來沒有被開發(fā)人員直接調(diào)用。而是WebHost在幕后自動調(diào)用配置方法。

ASP.NET團隊分析了這個設計，并與其他 Web 框架相比，認為設置涉及的東西太多。因此，最小的API概念誕生了。 現(xiàn)在，應用程序初始化可以全部包含在一個文件中。而且你可能感到奇怪，Main方法都不需要了?？梢栽趹迷O置中定義路由，從而大大減少代碼數(shù)量以啟動和運行一個應用程序。

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();
app.MapGet("/", () => "Hello World!");
app.Run();

當然如果你仍然喜歡將服務設置與應用配置分離的組織樣式，你仍然可以為 IServiceCollection 和 IApplicationBuilder 創(chuàng)建擴展方法，并從構建器和應用程序?qū)ο笳{(diào)用它們。

Hot Reload

幾年來，許多 Javascript 框架都支持熱重載，現(xiàn)在它也成為 C#中 ASP.NET Core應用的標配：通過熱重加載，您可以在應用運行期間（在調(diào)試器下）編輯您的 C#代碼，并且您的代碼更改將自動反映在您的應用中，而不會丟失應用狀態(tài)。換句話說，應用程序不需要重新啟動。對于調(diào)試和交互式開發(fā)工作流程來說，這應該是一個很好的改進。 這個功能對于開發(fā)來說非常重要，就是這個小功能微軟近日激怒了開源.NET社區(qū)，好消息是微軟聽取了社區(qū)的聲音，恢復了通過CLI支持HotReload功能。具體參見 http://www.fzitv.net/news/805653.html

Blazor

在 ASP.NET Core 6 里面有大量的更新是關于Blazor。例如，Blazor 應用程序現(xiàn)在可以直接編譯到 WebAssembly，以便在 IL 解釋（即.NET 本地編譯）版本的相同代碼上來提高應用程序速度。本地編譯/調(diào)試體驗仍然很快，因為漫長的編譯時間僅適用于包裝/發(fā)布。說到性能，Blazor WebAssembly可實現(xiàn)客戶端代碼的多線程。Javascript 受制于瀏覽器中的單線程。真正的多線程為可以從并行處理中受益的應用程序開辟了一些新的可能性（當然，這取決于瀏覽器的支持）。

還有一個非常有趣的功能，使 Blazor 可用于通過 MAUI 編寫桌面應用程序。 Blazor 的最大好處就是開發(fā)人員可以完全用 C# 編寫 Web 應用程序，而不需要為了寫前端必須切換到 Javascript。 如果沒有 C# 和 Javascript 之間的額外接縫，前端和后端代碼之間就不需要映射層。 可以在兩側(cè)使用相同的 C# 模型，這意味著需要的代碼更少，因此開發(fā)應用程序所需的時間也更少。 Blazor 桌面進一步擴展了這一概念，以允許此共享代碼現(xiàn)在也可以與桌面應用程序無縫集成。

MAUI

MAUI 是 Multi-platform App UI 的縮寫，是微軟對跨平臺 UI 框架的下一個嘗試。 MAUI 是 Xamarin 的演進，還包括桌面平臺。 它允許從單個代碼庫針對 iOS、Android、macOS 和 Windows。 MAUI 處理對本機平臺 API 的抽象，因此您可以以與平臺無關的方式訪問設備傳感器等內(nèi)容。 對 Xamarin 的一種印象是，它們最終得到的界面很少，而且在任何平臺上都不太好看。 MAUI 將如何解決這一問題還有待觀察。 如果你關心的是跨多個平臺的開發(fā)速度和維護成本，那么 MAUI 值得仔細研究。 MAUI 要在2022年的第二個季度正式發(fā)布，建議當前采取觀望的方法，進行小的嘗試以了解平臺在全面采用之前的長期發(fā)展方向。

 以上就是本文的全部內(nèi)容，希望對大家的學習有所幫助，也希望大家多多支持腳本之家。

最新評論