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