ASP.NET Core 5.0 的新增功能

本文重點介紹 ASP.NET Core 5.0 中最重要的更改，並提供相關文檔的鏈接。

ASP.NET Core MVC 和 :::no-loc(Razor)::: 改進

通過模型綁定將日期/時間綁定到 UTC

模型綁定現在支持將 UTC 時間字符串綁定到 DateTime。 如果請求包含 UTC 時間字符串，則模型綁定會將其綁定到 UTC DateTime。 例如，以下時間字符串會綁定到 UTC DateTime：https://example.com/mycontroller/myaction?time=2019-06-14T02%3A30%3A04.0576719Z

模型綁定和驗證與 C# 9 記錄類型一起使用

C# 9 記錄類型可以與 MVC 控制器或 :::no-loc(Razor)::: 頁面中的模型綁定一起使用。 記錄類型是為通過網絡傳輸的數據建模的好方法。

例如，以下 PersonController 將 Person 記錄類型與模型綁定和窗體驗證一起使用：

C#復制

 

public record Person([Required] string Name, [Range(0, 150)] int Age); public class PersonController { public IActionResult Index() => View(); [HttpPost] public IActionResult Index(Person person) { // ... } } 

Person/Index.cshtml 文件：

CSHTML復制

 

@model Person Name: <input asp-for="Model.Name" /> <span asp-validation-for="Model.Name" /> Age: <input asp-for="Model.Age" /> <span asp-validation-for="Model.Age" /> 

對 DynamicRouteValueTransformer 的改進

ASP.NET Core 3.1 引入了 DynamicRouteValueTransformer，作為使用自定義終結點動態選擇 MVC 控制器操作或 :::no-loc(Razor)::: 頁面的方法。 ASP.NET Core 5.0 應用可以將狀態傳遞到 DynamicRouteValueTransformer 並篩選選定的終結點集。

雜項

• [Compare] 特性可應用於 :::no-loc(Razor)::: 頁面模型上的屬性。
• 默認情況下，從正文中綁定的參數和屬性被視為必需。

Web API

OpenAPI 規范默認開啟

OpenAPI 規范是一種行業標准，用於描述 HTTP API 並將其集成到復雜的業務流程中或與第三方集成。 OpenAPI 受到所有雲提供程序和許多 API 注冊表的廣泛支持。 從 Web API 發出 OpenAPI 文檔的應用具有各種可使用這些 API 的新機會。 與開放源代碼項目 Swashbuckle.AspNetCore 的維護人員合作，ASP.NET Core API 模板包含對 Swashbuckle 的 NuGet 依賴關系。 Swashbuckle 是一個常用的開放源代碼 NuGet 包，可動態發出 OpenAPI 文檔。 Swashbuckle 通過 API 控制器進行自檢並在運行時或在生成時使用 Swashbuckle CLI 生成 OpenAPI 文檔來實現此目的。

在 ASP.NET Core 5.0 中，Web API 模板默認啟用 OpenAPI 支持。 若要禁用 OpenAPI，請執行以下操作：

• 通過命令行：

  .NET Core CLI復制

   

  dotnet new webapi --no-openapi true 

• 通過 Visual Studio：取消選中“啟用 OpenAPI 支持”。

為 Web API 項目創建的所有 .csproj 文件都包含 Swashbuckle.AspNetCore NuGet 包引用。

XML復制

 

<ItemGroup> <PackageReference Include="Swashbuckle.AspNetCore" Version="5.5.1" /> </ItemGroup> 

模板生成的代碼在 Startup.ConfigureServices 中包含用於激活 OpenAPI 文檔生成的代碼：

C#復制

 

public void ConfigureServices(IServiceCollection services) { services.AddControllers(); services.AddSwaggerGen(c => { c.SwaggerDoc("v1", new OpenApiInfo { Title = "WebApp1", Version = "v1" }); }); } 

Startup.Configure 方法將添加 Swashbuckle 中間件，這將啟用：

• 文檔生成過程。
• 在開發模式下默認為 Swagger UI 頁。

在發布到生產環境時，模板生成的代碼不會意外公開 API 的說明。

C#復制

 

public void Configure(IApplicationBuilder app, IWebHostEnvironment env) { if (env.IsDevelopment()) { app.UseDeveloperExceptionPage(); app.UseSwagger(); app.UseSwaggerUI(c => c.SwaggerEndpoint("/swagger/v1/swagger.json", "WebApp1 v1")); } app.UseHttpsRedirection(); app.UseRouting(); app.UseAuthorization(); app.UseEndpoints(endpoints => { endpoints.MapControllers(); }); } 

Azure API 管理導入

ASP.NET Core API 項目啟用 OpenAPI 時，Visual Studio 2019 版本 16.8 及更高版本將在發布流程中自動提供額外的步驟。 使用 Azure API 管理的開發人員有機會在發布流程中自動將 API 導入到 Azure API 管理：

更佳的 Web API 項目啟動體驗

如果默認啟用了 OpenAPI，則顯著改進了 Web API 開發人員的應用啟動體驗 (F5)。 借助 ASP.NET Core 5.0，Web API 模板會預先配置為加載 Swagger UI 頁。 Swagger UI 頁提供為已發布的 API 添加的文檔，並且單擊一次即可測試 API。

:::no-loc(Blazor):::

性能改進

對於 .NET 5，通過特別着重於復雜的 UI 呈現和 JSON 序列化顯著改進了 :::no-loc(Blazor WebAssembly)::: 運行時性能。 在我們的性能測試中，.NET 5 中 :::no-loc(Blazor WebAssembly)::: 的速度要比大多數情況快兩到三倍。 有關詳細信息，請參閱 ASP.NET 博客：.NET 5 候選發布版本 1 中的 ASP.NET Core 更新。

CSS 隔離

:::no-loc(Blazor)::: 現在支持定義限定為給定組件的 CSS 樣式。 使用組件特定的 CSS 樣式，可以更輕松地了解應用中的樣式，並避免全局樣式的意外副作用。 有關詳細信息，請參閱 ASP.NET Core Blazor CSS 隔離。

新的 InputFile 組件

InputFile 組件允許讀取用戶選擇要上傳的一個或多個文件。 有關詳細信息，請參閱 ASP.NET Core :::no-loc(Blazor)::: 文件上傳。

新的 InputRadio 和 InputRadioGroup 組件

:::no-loc(Blazor)::: 具有內置的 InputRadio 和 InputRadioGroup 組件，這些組件可簡化通過集成驗證將數據綁定到單選按鈕組。 有關詳細信息，請參閱 ASP.NET Core Blazor 窗體和驗證。

組件虛擬化

使用 :::no-loc(Blazor)::: 框架的內置虛擬化支持提高組件呈現的感知性能。 有關詳細信息，請參閱 ASP.NET Core Blazor 窗體和驗證。

ontoggle 事件支持

:::no-loc(Blazor)::: 事件現在支持 ontoggle DOM 事件。 有關詳細信息，請參閱 ASP.NET Core Blazor 事件處理。

將 UI 焦點設置在 :::no-loc(Blazor)::: 應用中

對元素引用使用 FocusAsync 便捷方法，以便將 UI 焦點設置到該元素。 有關詳細信息，請參閱 ASP.NET Core Blazor 事件處理。

自定義驗證類屬性

與 CSS 框架集成時，自定義驗證類名稱非常有用，例如啟動。 有關詳細信息，請參閱 ASP.NET Core Blazor 窗體和驗證。

IAsyncDisposable 支持

:::no-loc(Blazor)::: 組件現在支持已分配資源的異步版本的 IAsyncDisposable 接口。

JavaScript 隔離和對象引用

:::no-loc(Blazor)::: 在標准 JavaScript 模塊中啟用 JavaScript 隔離。 有關詳細信息，請參閱 在 ASP.NET Core :::no-loc(Blazor)::: 中從 .NET 方法調用 JavaScript 函數。

窗體組件支持顯示名稱

以下內置組件支持帶有 DisplayName 參數的顯示名稱：

• InputDate
• InputNumber
• InputSelect

有關詳細信息，請參閱 ASP.NET Core Blazor 窗體和驗證。

catch-all 路由參數

組件支持可跨多個文件夾邊界捕獲路徑的 catch-all 路由參數。 有關詳細信息，請參閱 ASP.NET Core Blazor 路由。

調試改進

調試 :::no-loc(Blazor WebAssembly)::: 應用在 ASP.NET Core 5.0 中得到了改進。 此外，Visual Studio for Mac 上現在也支持調試。 有關詳細信息，請參閱 調試 ASP.NET Core Blazor WebAssembly。

Microsoft :::no-loc(Identity)::: v2.0 和 MSAL v2.0

:::no-loc(Blazor)::: 安全性現在使用 Microsoft :::no-loc(Identity)::: v2.0（Microsoft.:::no-loc(Identity):::.Web 和 Microsoft.:::no-loc(Identity):::.Web.UI）和 MSAL v2.0。 有關詳細信息，請參閱:::no-loc(Blazor)::: 安全性和 :::no-loc(Identity)::: 節點中的主題。

:::no-loc(Blazor Server)::: 受保護的瀏覽器存儲

:::no-loc(Blazor Server)::: 應用現在可以使用內置支持在瀏覽器中存儲應用狀態，這已受到保護，無法使用 ASP.NET Core 數據保護進行篡改。 數據可以存儲在本地瀏覽器存儲或會話存儲中。 有關詳細信息，請參閱 ASP.NET Core Blazor 狀態管理。

:::no-loc(Blazor WebAssembly)::: 預呈現

跨托管模型改進了組件集成，:::no-loc(Blazor WebAssembly)::: 應用現在可以在服務器上預呈現輸出。

剪裁/鏈接改進

:::no-loc(Blazor WebAssembly)::: 在生成期間執行中間語言 (IL) 剪裁/鏈接，以從應用的輸出程序集中剪裁不必要的 IL。 隨着 ASP.NET Core 5.0 的發布，:::no-loc(Blazor WebAssembly)::: 通過其他配置選項來執行改進的剪裁。 有關詳細信息，請參閱 配置適用於 ASP.NET Core Blazor 的裁邊器 和剪裁選項。

瀏覽器兼容性分析器

:::no-loc(Blazor WebAssembly)::: 應用面向整個 .NET API 外圍應用，但由於瀏覽器沙盒約束，並非所有 .NET API 在 WebAssembly 上都受支持。 在 WebAssembly 上運行時，不支持的 API 將引發 PlatformNotSupportedException。 當應用使用應用目標平台不支持的 API 時，平台兼容性分析器會向開發人員發出警告。 有關詳細信息，請參閱 ASP.NET Core Razor 組件類庫。

延遲加載程序集

通過推遲某些應用程序程序集的加載，直到需要時才加載，來提高 :::no-loc(Blazor WebAssembly)::: 應用啟動性能。 有關詳細信息，請參閱 在 ASP.NET Core Blazor WebAssembly 中延遲加載程序集。

已更新的全球化支持

全球化支持適用於基於 International Components for Unicode (ICU) 的 :::no-loc(Blazor WebAssembly):::。 有關詳細信息，請參閱 ASP.NET Core Blazor 全球化和本地化。

gRPC

在 gRPC 中進行了許多性能改進。 有關詳細信息，請參閱 .NET 5 中的 gRPC 性能改進。

有關 gRPC 的詳細信息，請參閱 .NET Core 上的 gRPC 的簡介。

:::no-loc(SignalR):::

:::no-loc(SignalR)::: 中心篩選器（在 ASP.NET :::no-loc(SignalR)::: 中稱為“中心管道”）是一項功能，它允許代碼在調用中心方法之前和之后運行。 在調用中心方法之前和之后運行代碼類似於中間件在 HTTP 請求之前和之后運行代碼。 常見用途包括日志記錄、錯誤處理和參數驗證。

有關詳細信息，請參閱在 ASP.NET Core :::no-loc(SignalR)::: 中使用中心篩選器。

:::no-loc(SignalR)::: 並行中心調用

ASP.NET Core :::no-loc(SignalR)::: 現在能夠處理並行中心調用。 可以更改默認行為，以允許客戶端一次調用多個中心方法：

 警告

你要查找的示例似乎已移動！ 不要擔心，我們正在努力解決此問題。

在 :::no-loc(SignalR)::: Java 客戶端中添加了 Messagepack 支持

新包 (com.microsoft.signalr.messagepack) 將 MessagePack 支持添加到 :::no-loc(SignalR)::: Java 客戶端。 若要使用 MessagePack 中心協議，請將 .withHubProtocol(new MessagePackHubProtocol()) 添加到連接生成器：

Java復制

 

HubConnection hubConnection = HubConnectionBuilder.create(
                           "http://localhost:53353/MyHub") .withHubProtocol(new MessagePackHubProtocol()) .build(); 

:::no-loc(Kestrel):::

• 通過配置可重載的終結點：:::no-loc(Kestrel)::: 可以檢測對傳遞到 :::no-loc(Kestrel):::ServerOptions.Configure 的配置所做的更改，從現有終結點取消綁定並綁定到新終結點，而無需在 reloadOnChange 參數 true 時重新啟動應用程序。 默認情況下，在使用 ConfigureWebHostDefaults 或 CreateDefaultBuilder 時，:::no-loc(Kestrel)::: 將綁定到啟用了 reloadOnChange 的“:::no-loc(Kestrel):::”配置子節。 手動調用 :::no-loc(Kestrel):::ServerOptions.Configure 以獲取可重載終結點時，應用必須傳遞 reloadOnChange: true。

• HTTP/2 響應標頭改進。 有關詳細信息，請參閱下一部分中的性能改進。

• 支持套接字傳輸中的其他終結點類型：添加到 System.Net.Sockets 中引入的新 API，:::no-loc(Kestrel)::: 中的套接字默認傳輸允許綁定到現有文件句柄和 Unix 域套接字。 如果支持綁定到現有文件句柄，則無需 libuv 傳輸即可使用現有 Systemd 集成。

• :::no-loc(Kestrel)::: 中的自定義標頭解碼：應用可以指定使用哪個 Encoding 來基於標頭名稱解釋傳入標頭，而不是默認為 UTF-8。 在包含身份驗證方案、帳戶名和身份驗證簽名的字符串中設置 Microsoft.AspNetCore.Server.:::no-loc(Kestrel):::.:::no-loc(Kestrel):::ServerOptions.RequestHeaderEncodingSelector 屬性用於指定要使用的編碼：

  C#復制

   

  public static IHostBuilder CreateHostBuilder(string[] args) => Host.CreateDefaultBuilder(args) .ConfigureWebHostDefaults(webBuilder => { webBuilder.Configure:::no-loc(Kestrel):::(options => { options.RequestHeaderEncodingSelector = encoding => { return encoding switch { "Host" => System.Text.Encoding.Latin1, _ => System.Text.Encoding.UTF8, }; }; }); webBuilder.UseStartup<Startup>(); }); 

通過配置的 :::no-loc(Kestrel)::: 終結點特定選項

添加了通過配置來配置 :::no-loc(Kestrel)::: 的終結點特定選項的支持。 終結點特定的配置包括：

• 已使用 HTTP 協議
• 已使用 TLS 協議
• 已選擇證書
• 客戶端證書模式

配置允許指定基於指定服務器名稱選擇的證書。 服務器名稱是客戶端所指示的 TLS 協議的服務器名稱指示 (SNI) 擴展的一部分。 :::no-loc(Kestrel)::: 的配置還支持在主機名中使用通配符前綴。

下面的示例演示如何使用配置文件指定終結點特定的配置：

JSON復制

 

{
  ":::no-loc(Kestrel):::": { "Endpoints": { "EndpointName": { "Url": "https://*", "Sni": { "a.example.org": { "Protocols": "Http1AndHttp2", "SslProtocols": [ "Tls11", "Tls12"], "Certificate": { "Path": "testCert.pfx", "Password": "testPassword" }, "ClientCertificateMode" : "NoCertificate" }, "*.example.org": { "Certificate": { "Path": "testCert2.pfx", "Password": "testPassword" } }, "*": { // At least one sub-property needs to exist per // SNI section or it cannot be discovered via // IConfiguration "Protocols": "Http1", } } } } } } 

服務器名稱指示 (SNI) 是一種 TLS 擴展，可將虛擬域作為 SSL 協商的一部分包括在內。 這實際上表示虛擬域名或主機名可用於標識網絡終結點。

性能改進

HTTP/2

• 顯著減少了 HTTP/2 代碼路徑中的分配。

• 支持 :::no-loc(Kestrel)::: 中的 HTTP/2 響應標頭的 HPack 動態壓縮。 有關詳細信息，請參閱標頭表大小和 HPACK：HTTP/2 的靜默殺手鐧。

• 發送 HTTP/2 PING 幀：HTTP/2 有一種機制，用於發送 PING 幀以確保空閑連接仍然正常工作。 當使用經常空閑但僅可間歇查看活動的長生存期流（例如，gRPC 流）時，確保可行連接特別有用。 應用可以通過對 <xref:Microsoft.AspNetCore.Server.:::no-loc(Kestrel):::.:::no-loc(Kestrel):::ServerOptions> 設置限制，在 :::no-loc(Kestrel)::: 中發送定期 PING 幀：

  C#復制

   

  public static IHostBuilder CreateHostBuilder(string[] args) => Host.CreateDefaultBuilder(args) .ConfigureWebHostDefaults(webBuilder => { webBuilder.Configure:::no-loc(Kestrel):::(options => { options.Limits.Http2.KeepAlivePingInterval = TimeSpan.FromSeconds(10); options.Limits.Http2.KeepAlivePingTimeout = TimeSpan.FromSeconds(1); }); webBuilder.UseStartup<Startup>(); }); 

容器

在 .NET 5.0 之前，生成並發布用於 ASP.NET Core 應用的 Dockerfile 需要提取整個 .NET Core SDK 和 ASP.NET Core 映像。 在此版本中，將減少提取 SDK 圖像字節數，並大大消除為 ASP.NET Core 映像提取的字節數。 有關詳細信息，請參閱此 GitHub 問題注釋。

身份驗證和授權

使用 Microsoft.:::no-loc(Identity):::.Web 的 Azure Active Directory 身份驗證

ASP.NET Core 項目模板現在與 <xref:Microsoft.:::no-loc(Identity):::.Web?displayProperty=fullName> 集成，以處理使用 Azure Activity Directory (Azure AD) 的身份驗證。 Microsoft.:::no-loc(Identity):::.Web package 提供：

• 通過 Azure AD 進行身份驗證的更好體驗。
• 代表用戶訪問 Azure 資源的一種更簡單方法，包括 Microsoft Graph。 請參閱 Microsoft.:::no-loc(Identity):::.Web sample，它從基本登錄開始，通過多租戶（使用 Azure API、使用 Microsoft Graph 並保護你自己的 API）前進。 Microsoft.:::no-loc(Identity):::.Web 與 .NET 5 一起提供。

允許匿名訪問終結點

AllowAnonymous 擴展方法允許匿名訪問終結點：

C#復制

 

public void Configure(IApplicationBuilder app, IWebHostEnvironment env) { app.UseRouting(); app.UseAuthentication(); app.UseAuthorization(); app.UseEndpoints(endpoints => { endpoints.MapGet("/", async context => { await context.Response.WriteAsync("Hello World!"); }) .AllowAnonymous(); }); } 

自定義處理授權失敗

現在，使用由授權中間件調用的新 IAuthorizationMiddlewareResultHandler 接口可以更輕松地自定義處理授權失敗。 默認實現保持不變，但可以在“依賴關系注入”中注冊自定義處理程序，這允許基於授權失敗的原因發出自定義 HTTP 響應。 請參閱用於演示 IAuthorizationMiddlewareResultHandler 的使用情況的此示例。

使用終結點路由時的授權

使用終結點路由時的授權現在會接收 HttpContext 而不是終結點實例。 這允許授權中間件訪問 RouteData 以及無法通過 Endpoint 類訪問的 HttpContext 的其他屬性。 可以使用 context.GetEndpoint 從上下文中提取終結點。

使用 Linux 上的 Kerberos 身份驗證和 LDAP 的基於角色的訪問控制

請參閱 Kerberos 身份驗證和基於角色的訪問控制 (RBAC)

API 改進

用於 HttpRequest 和 HttpResponse 的 JSON 擴展方法

可以使用新的 ReadFromJsonAsync 和 WriteAsJsonAsync 擴展方法從 HttpRequest 和 HttpResponse 讀取和寫入 JSON 數據。 這些擴展方法使用 System.Text.Json 序列化程序來處理 JSON 數據。 新的 HasJsonContentType 擴展方法還可以檢查請求是否具有 JSON 內容類型。

JSON 擴展方法可與終結點路由結合使用，以編程方式創建 JSON API，我們稱之為“路由到代碼”*_。 這是一個新選項，適用於想要以輕量級方式創建基本 JSON API 的開發人員。 例如，只有少量終結點的 Web 應用可能選擇使用路由到代碼，而不是 ASP.NET Core MVC 的全部功能：

C#復制

 

endpoints.MapGet("/weather/{city:alpha}", async context => { var city = (string)context.Request.RouteValues["city"]; var weather = GetFromDatabase(city); await context.Response.WriteAsJsonAsync(weather); }); 

有關新 JSON 擴展方法以及路由到代碼的詳細信息，請參閱此 .NET show。

System.Diagnostics.Activity

System.Diagnostics.Activity 的默認格式現在默認為 W3C 格式。 默認情況下，這使得 ASP.NET Core 中的分布式跟蹤支持可與更多框架進行互操作。

FromBodyAttribute

FromBodyAttribute 現在支持配置允許將這些參數或屬性視為可選的選項：

C#復制

 

public IActionResult Post([FromBody(EmptyBodyBehavior = EmptyBodyBehavior.Allow)] MyModel model) { ... } 

其他改進

我們已開始將可以為 null 的注釋應用到 ASP.NET Core 程序集。 我們計划為 .NET 5 Framework 的大多數常見公共 API 圖面添加批注。

控制 Startup 類激活

添加了額外的 UseStartup 重載，使應用能夠提供工廠方法來控制 Startup 類激活。 控制 Startup 類激活有助於將附加參數傳遞給與主機一起初始化的 Startup：

C#復制

 

public class Program { public static async Task Main(string[] args) { var logger = CreateLogger(); var host = Host.CreateDefaultBuilder() .ConfigureWebHost(builder => { builder.UseStartup(context => new Startup(logger)); }) .Build(); await host.RunAsync(); } } 

使用 dotnet watch 自動刷新

在 .NET 5 中，對 ASP.NET Core 項目運行 dotnet watch 將啟動默認瀏覽器，並在對代碼進行更改時自動刷新瀏覽器。 這意味着可以執行下列操作：

_ 在文本編輯器中打開 ASP.NET Core 項目。

• 運行 dotnet watch。
• 專注於代碼更改，而工具處理應用的重新生成、重新啟動和重新加載。

我們希望將來能將自動刷新功能引入 Visual Studio。

控制台記錄器格式化程序

已對 Microsoft.Extensions.Logging 庫中的控制台日志提供程序進行了改進。 開發人員現在可以實現自定義 ConsoleFormatter，以對控制台輸出的格式設置和着色進行完全控制。 格式化程序 API 通過實現 VT-100 轉義序列的子集進行豐富的格式設置。 VT-100 受大多數新式終端支持。 控制台記錄器可以對不受支持的終端分析轉義序列，使開發人員可以為所有終端創作單個格式化程序。

JSON 控制台記錄器

除了對自定義格式化程序的支持外，我們還添加了一個內置 JSON 格式化程序，用於向控制台發出結構化 JSON 日志。 下面的代碼演示如何從默認記錄器切換到 JSON：

C#復制

 

public static IHostBuilder CreateHostBuilder(string[] args) => Host.CreateDefaultBuilder(args) .ConfigureLogging(logging => { logging.AddJsonConsole(options => { options.JsonWriterOptions = new JsonWriterOptions() { Indented = true }; }); }) .ConfigureWebHostDefaults(webBuilder => { webBuilder.UseStartup<Startup>(); }); 

發出到控制台的日志消息為 JSON 格式：

JSON復制

 

{
  "EventId": 0, "LogLevel": "Information", "Category": "Microsoft.Hosting.Lifetime", "Message": "Now listening on: https://localhost:5001", "State": { "Message": "Now listening on: https://localhost:5001", "address": "https://localhost:5001", "{OriginalFormat}": "Now listening on: {address}" } } 

https://docs.microsoft.com/zh-cn/aspnet/core/release-notes/aspnetcore-5.0?view=aspnetcore-5.0

關注公眾號：UP技術控   獲取更多資訊