ASP.NET Core 5.0 の新機能
この記事では、ASP.NET Core 5.0 の最も大きな変更点について説明します。また、関連するドキュメントへのリンクも示します。
ASP.NET Core MVC と Razor の機能強化
UTC としての DateTime のモデル バインド
モデル バインドにおいて、UTC 時刻文字列の DateTime
へのバインドがサポートされるようになりました。 要求に UTC 時刻文字列が含まれている場合は、モデル バインドによって UTC DateTime
にバインドされます。 たとえば、次の時刻文字列は UTC DateTime
にバインドされます: https://example.com/mycontroller/myaction?time=2019-06-14T02%3A30%3A04.0576719Z
C# 9 のレコード型を使用したモデル バインドと検証
C# 9 のレコード型を、MVC コントローラーまたは Razor ページのモデル バインドと共に使用することができます。 レコード型は、ネットワーク経由で転送されるデータをモデル化するための優れた方法です。
たとえば、次の PersonController
では、モデル バインドとフォーム検証で Person
レコード型が使用されます。
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
ファイルは以下の通りです。
@model Person
<label>Name: <input asp-for="Model.Name" /></label>
<span asp-validation-for="Model.Name" />
<label>Age: <input asp-for="Model.Age" /></label>
<span asp-validation-for="Model.Age" />
DynamicRouteValueTransformer の機能強化
ASP.NET Core 3.1 では、カスタム エンドポイントを使用して MVC コントローラーのアクションまたは Razor ページを動的に選択するための方法として、DynamicRouteValueTransformer が導入されました。 ASP.NET Core 5.0 アプリでは、DynamicRouteValueTransformer
に状態を渡して、選択されたエンドポイントのセットをフィルター処理できます。
その他
- [Compare] 属性は Razor ページ モデルのプロパティに適用できます。
- 本文からバインドされたパラメーターとプロパティは、既定では必須と見なされます。
Web API
OpenAPI 仕様を規定で有効化
OpenAPI 仕様は、HTTP API について記述し、それらを複雑なビジネス プロセスやサード パーティと統合するための業界標準です。 OpenAPI はすべてのクラウド プロバイダーと多くの API レジストリによって幅広くサポートされています。 アプリによって Web API から OpenAPI ドキュメントを出力できれば、これらの API を使用できるさまざまな新しい機会を得られます。 オープンソース プロジェクト Swashbuckle.AspNetCore の保守管理者との連携により、ASP.NET Core API テンプレートには Swashbuckle への NuGet の依存関係が含まれています。 Swashbuckle は、OpenAPI ドキュメントを動的に生成する、広く普及しているオープンソース NuGet パッケージです。 Swashbuckle でこれを実行するには、実行時に API コントローラーを調べて OpenAPI ドキュメントを生成するか、または Swashbuckle CLI を使用してビルド時に生成します。
ASP.NET Core 5.0 では、Web API テンプレートによって既定で OpenAPI サポートが有効になります。 OpenAPI を無効にするには:
コマンドラインから:
dotnet new webapi --no-openapi true
Visual Studio から: [Enable OpenAPI support](OpenAPI サポートの有効化) をオフにします。
Web API プロジェクト用に作成されたすべての .csproj
ファイルには、Swashbuckle.AspNetCore NuGet パッケージ参照が含まれます。
<ItemGroup>
<PackageReference Include="Swashbuckle.AspNetCore" Version="5.5.1" />
</ItemGroup>
テンプレートによって生成されたコードには、OpenAPI ドキュメントの生成をアクティブにするコードが Startup.ConfigureServices
に含まれます。
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 の説明が誤って公開されることはありません。
public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
if (env.IsDevelopment())
{
app.UseDeveloperExceptionPage();
app.UseSwagger(); // UseSwaggerUI Protected by if (env.IsDevelopment())
app.UseSwaggerUI(c => c.SwaggerEndpoint("/swagger/v1/swagger.json",
"WebApp1 v1"));
}
app.UseHttpsRedirection();
app.UseRouting();
app.UseAuthorization();
app.UseEndpoints(endpoints =>
{
endpoints.MapControllers();
});
}
Azure API Management のインポート
ASP.NET Core API プロジェクトで OpenAPI が有効になっている場合、Visual Studio 2019 バージョン 16.8 以降の発行では、発行フローに追加の手順が自動的に提示されます。 Azure API Management を使用する開発者は、発行フロー中に、API を Azure API Management に自動的にインポートすることを選択できます。
Web API プロジェクトの起動エクスペリエンスの向上
OpenAPI が既定で有効になっている場合、Web API 開発者のアプリ起動エクスペリエンス (F5) が大幅に改善されます。 ASP.NET Core 5.0 では、Web API テンプレートが Swagger UI ページを読み込むように事前構成されています。 Swagger UI ページには、発行された API 用に追加されるドキュメントと、1 回のクリックで API をテストする機能の両方が用意されています。
Blazor
パフォーマンスの向上
.NET 5 では、複雑な UI レンダリングと JSON シリアル化に特に重点を置いて、.NET WebAssembly ランタイムのパフォーマンスが大幅に改善されました。 Microsoft によるパフォーマンス テストでは、.NET 5 の Blazor WebAssembly はほとんどのシナリオで 2 倍から 3 倍高速になりました。 詳細については、ASP.NET ブログ:.NET 5 リリース候補 1 における ASP.NET Core の更新に関するページを参照してください。
CSS の分離
Blazor では、特定のコンポーネントにスコープ設定された CSS スタイルの定義がサポートされるようになりました。 コンポーネント固有の CSS スタイルを使用すると、アプリのスタイルを把握しやすくなり、グローバル スタイルにおける意図しない副作用を回避しやすくなります。 詳細については、「ASP.NET Core Blazor の CSS の分離」を参照してください
新しい InputFile
コンポーネント
InputFile
コンポーネントを使用すると、アップロード用にユーザーが選択した 1 つ以上のファイルを読み取ることができます。 詳細については、「ASP.NET Core Blazor ファイルのアップロード」を参照してください
新しい InputRadio
および InputRadioGroup
コンポーネント
Blazor に、ラジオ ボタン グループへのデータ バインドを簡略化する、統合された検証機能を備えた InputRadio
および InputRadioGroup
コンポーネントが組み込まれています。 詳細については、「ASP.NET Core Blazor 入力コンポーネント」を参照してください。
コンポーネントの仮想化
Blazor フレームワークに組み込まれている仮想化サポートを使用して、コンポーネント レンダリングの認識されるパフォーマンスを向上させます。 詳しくは、「ASP.NET Core Razor コンポーネントの仮想化」をご覧ください。
ontoggle
イベントのサポート
Blazor イベントで ontoggle
DOM イベントがサポートされるようになりました。 詳細については、「ASP.NET Core Blazor のイベント処理」を参照してください。
Blazor アプリで UI フォーカスを設定する
要素参照で便利なメソッド FocusAsync
を使用して、UI フォーカスをその要素に設定できます。 詳細については、「ASP.NET Core Blazor のイベント処理」を参照してください。
カスタム検証 CSS クラスの属性
カスタム検証 CSS クラスの属性は、Bootstrap などの CSS フレームワークと統合する場合に便利です。 詳細については、「ASP.NET Core Blazor フォームの検証」を参照してください。
IAsyncDisposable のサポート
Razor コンポーネントで、割り当てられたリソースの非同期リリース用に IAsyncDisposable インターフェイスがサポートされるようになりました。
JavaScript の分離とオブジェクト参照
Blazor により、標準 JavaScript モジュールで JavaScript の分離が有効にされます。 詳しくは、「ASP.NET Core Blazor で .NET メソッドから JavaScript 関数を呼び出す」をご覧ください。
フォーム コンポーネントでの表示名のサポート
次の組み込みコンポーネントでは、DisplayName
パラメーターを使用した表示名がサポートされています。
InputDate
InputNumber
InputSelect
詳細については、「ASP.NET Core Blazor のフォームの概要」を参照してください。
キャッチオールのルート パラメーター
複数のフォルダー境界にまたがるパスをキャプチャするキャッチオール ルート パラメーターが、コンポーネントでサポートされます。 詳細については、「ASP.NET Core の Blazor ルーティングとナビゲーション」を参照してください。
デバッグの機能強化
ASP.NET Core 5.0 では Blazor WebAssembly アプリのデバッグが改善されました。 さらに、Visual Studio for Mac でデバッグがサポートされるようになりました。 詳細については、「ASP.NET Core Blazor アプリをデバッグする」を参照してください。
Microsoft Identity v2.0 および MSAL v2.0
Blazor セキュリティで Microsoft Identity v2.0 (Microsoft.Identity.Web
と Microsoft.Identity.Web.UI
) および MSAL v2.0 が使用されるようになりました。 詳細については、Blazor セキュリティと Identity ノードに関するトピックを参照してください。
Blazor Server の保護されたブラウザー ストレージ
Blazor Server アプリでは、ASP.NET Core データ保護を使用して改ざんから保護されているブラウザーにアプリの状態を格納するための、組み込みサポートを使用できるようになりました。 データは、ローカルのブラウザー ストレージまたはセッション ストレージに格納できます。 詳細については、「ASP.NET Core Blazor 状態管理」を参照してください。
Blazor WebAssembly のプリレンダリング
コンポーネントの統合がホスティング モデル全体で向上し、Blazor WebAssembly アプリがサーバーで出力をプリレンダリングできるようになりました。
トリミングとリンクの機能強化
Blazor WebAssembly では、ビルド中に中間言語 (IL) のトリミングとリンクが実行され、アプリの出力アセンブリから不要な IL がトリミングされます。 ASP.NET Core 5.0 リリースでは、Blazor WebAssembly により、追加の構成オプションを備えた改善されたトリミングが実行されます。 詳細については、「ASP.NET Core Blazor 用のトリマーを構成する」と「トリミングのオプション」を参照してください。
ブラウザー互換性アナライザー
Blazor WebAssembly アプリは完全な .NET API 領域を対象としていますが、ブラウザー サンドボックスの制約により、すべての .NET API が WebAssembly でサポートされているわけではありません。 サポートされていない API は、WebAssembly で実行すると PlatformNotSupportedException がスローされます。 開発者が、アプリのターゲット プラットフォームでサポートされていない API をアプリで使用すると、プラットフォーム互換性アナライザーから警告を受け取ります。 詳細については、「ASP.NET Core Razor コンポーネントを Razor クラス ライブラリから使用する」を参照してください。
アセンブリの遅延読み込み
Blazor WebAssembly アプリの起動時のパフォーマンスは、一部のアプリケーション アセンブリの読み込みを必要になるまで延期することで改善できます。 詳しくは、「ASP.NET Core Blazor WebAssembly でのアセンブリの遅延読み込み」をご覧ください。
グローバリゼーション サポートの更新
International Components for Unicode (ICU) に基づき Blazor WebAssembly でグローバリゼーション サポートを利用できます。 詳細については、「ASP.NET Core Blazor のグローバリゼーションおよびローカライズ」を参照してください。
gRPC
gRPC では、多くのパフォーマンス改善が行われています。 詳細については、「.NET 5 での gRPC のパフォーマンスの向上」を参照してください。
gRPC の詳細については、「.NET の gRPC の概要」を参照してください。
SignalR
SignalR ハブ フィルター
SignalR ハブ フィルター (ASP.NET SignalR のハブ パイプラインと呼ばれます) は、ハブ メソッドが呼び出される前と後にコードを実行できる機能です。 ハブ メソッドが呼び出される前と後のコードの実行は、ミドルウェアが HTTP 要求の前と後にコードを実行する機能に似ています。 一般的な使用方法としては、ログ記録、エラー処理、引数の検証などがあります。
詳細については、「ASP.NET Core SignalR のハブ フィルターを使用する」を参照してください。
SignalR 並列ハブ呼び出し
ASP.NET Core SignalR では、並列ハブ呼び出しを処理できるようになりました。 既定の動作を変更して、クライアントが一度に複数のハブ メソッドを呼び出せるようにすることができます。
public void ConfigureServices(IServiceCollection services)
{
services.AddSignalR(options =>
{
options.MaximumParallelInvocationsPerClient = 5;
});
}
SignalR Java クライアントへの Messagepack サポートの追加
新しいパッケージ com.microsoft.signalr.messagepack によって、SignalR Java クライアントに MessagePack サポートが追加されます。 MessagePack ハブ プロトコルを使用するには、接続ビルダーに .withHubProtocol(new MessagePackHubProtocol())
を追加します。
HubConnection hubConnection = HubConnectionBuilder.create(
"http://localhost:53353/MyHub")
.withHubProtocol(new MessagePackHubProtocol())
.build();
Kestrel
構成を使用して再読み込み可能なエンドポイント: Kestrel では、
reloadOnChange
パラメーターがtrue
の場合、KestrelServerOptions.Configure に渡された構成の変更を検出し、アプリケーションを再起動することなく、既存のエンドポイントからバインド解除して、新しいエンドポイントにバインドすることができます。 既定では、ConfigureWebHostDefaults または CreateDefaultBuilder を使用する場合、Kestrel はreloadOnChange
が有効な "Kestrel" 構成サブセクションにバインドされます。 アプリでは、KestrelServerOptions.Configure
を手動で呼び出す際にreloadOnChange: true
を渡して、再読み込み可能なエンドポイントを取得する必要があります。HTTP/2 応答ヘッダーの機能強化。 詳細については、次のセクションの「パフォーマンスの向上」を参照してください。
ソケット転送における追加のエンドポイントの種類のサポート:System.Net.Sockets に導入された新しい API に加えて、Kestrel の既定のソケット転送で、既存のファイル ハンドルと Unix ドメイン ソケットの両方にバインドできるようになります。 既存のファイル ハンドルへのバインドのサポートによって、
libuv
転送を必要とせずに、既存のSystemd
統合を使用できるようになります。Kestrel でのカスタム ヘッダーのデコード:アプリでは、既定の UTF-8 の代わりに、ヘッダー名に基づいて受信ヘッダーを解釈するために使用する Encoding を指定できます。 使用するエンコードを指定するには、
Microsoft.AspNetCore.Server.Kestrel.KestrelServerOptions.RequestHeaderEncodingSelector
プロパティを設定します。public static IHostBuilder CreateHostBuilder(string[] args) => Host.CreateDefaultBuilder(args) .ConfigureWebHostDefaults(webBuilder => { webBuilder.ConfigureKestrel(options => { options.RequestHeaderEncodingSelector = encoding => { return encoding switch { "Host" => System.Text.Encoding.Latin1, _ => System.Text.Encoding.UTF8, }; }; }); webBuilder.UseStartup<Startup>(); });
構成を使用した Kestrel エンドポイント固有のオプション
構成を使用して Kestrel のエンドポイント固有のオプションを構成するためのサポートが追加されました。 エンドポイント固有の構成には、次が含まれます。
- 使用される HTTP プロトコル
- 使用される TLS プロトコル
- 選択される証明書
- クライアント証明書モード
構成によって、指定したサーバー名に基づいてどの証明書が選択されるかを指定できます。 サーバー名は、クライアントによって示される、TLS プロトコルの Server Name Indication (SNI) 拡張機能の一部です。 Kestrel の構成では、ホスト名のワイルドカード プレフィックスもサポートされています。
構成ファイルを使用してエンドポイント固有の設定を指定する方法を次の例に示します。
{
"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",
}
}
}
}
}
}
Server Name Indication (SNI) は、SSL ネゴシエーションの一部として仮想ドメインを含めるための TLS 拡張機能です。 これは実質的に、仮想ドメイン名 (またはホスト名) を使用してネットワーク エンドポイントを識別できることを意味します。
パフォーマンスの向上
HTTP/2
HTTP/2 コード パスでの割り当ての大幅な削減。
Kestrel での HTTP/2 応答ヘッダーの HPack 動的圧縮のサポート。 詳細については、「ヘッダー テーブルのサイズ」と「HPACK: HTTP/2 のサイレント機能」を参照してください。
HTTP/2 PING フレームの送信:HTTP/2 には、アイドル状態の接続がまだ機能していることを確認するために PING フレームを送信するメカニズムがあります。 実行可能な接続であることの確認は、アイドル状態であることが多いが間欠的にアクティビティが発生する、長期間存在するストリームを使用する場合に特に便利です。たとえば、gRPC ストリームなどです。 アプリでは、KestrelServerOptions に制限を設定することによって、Kestrel で定期的に PING フレームを送信できます。
public static IHostBuilder CreateHostBuilder(string[] args) => Host.CreateDefaultBuilder(args) .ConfigureWebHostDefaults(webBuilder => { webBuilder.ConfigureKestrel(options => { options.Limits.Http2.KeepAlivePingInterval = TimeSpan.FromSeconds(10); options.Limits.Http2.KeepAlivePingTimeout = TimeSpan.FromSeconds(1); }); webBuilder.UseStartup<Startup>(); });
Containers
.NET 5.0 より前のバージョンでは、ASP.NET Core アプリの Dockerfile をビルドして発行するには、.NET Core SDK と ASP.NET Core のイメージ全体をプルする必要がありました。 このリリースでは、SDK イメージをプルするバイトが削減され、ASP.NET Core イメージ用にプルされるバイトの大部分が削除されます。 詳細については、こちらの GitHub イシューのコメントを参照してください
認証と承認
Microsoft.Identity.Web での Microsoft Entra ID 認証
ASP.NET Core のプロジェクト テンプレートが Microsoft.Identity.Web と統合され、Microsoft Entra ID での認証を処理できるようになりました。 Microsoft.Identity.Web パッケージには次が備わっています。
- Microsoft Entra ID を使用した認証のエクスペリエンスが向上します。
- Microsoft Graph など、ユーザーに代わって Azure リソースにアクセスするための簡単な方法。 Microsoft.Identity.Web のサンプルを参照してください。これは基本的なログインから始まり、マルチテナント、Azure API の使用、Microsoft Graph の使用、独自の API の保護に進んでいきます。
Microsoft.Identity.Web
は .NET 5 と共に使用できます。
エンドポイントへの匿名アクセスを許可する
AllowAnonymous
拡張メソッドを使用すると、エンドポイントへの匿名アクセスを許可できます。
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
を受信するようになりました。 これにより、認可ミドルウェアで、Endpoint クラスではアクセスできなかった RouteData
や 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 の完全な機能ではなく、コードへのルーティングを使用することができます。
endpoints.MapGet("/weather/{city:alpha}", async context =>
{
var city = (string)context.Request.RouteValues["city"];
var weather = GetFromDatabase(city);
await context.Response.WriteAsJsonAsync(weather);
});
System.Diagnostics.Activity
System.Diagnostics.Activity の既定の形式が W3C 形式になりました。 これにより、ASP.NET Core での分散トレースのサポートが、既定でより多くのフレームワークと相互運用できるようになります。
FromBodyAttribute
FromBodyAttribute で、次のパラメーターまたはプロパティを省略可能と見なすことができるオプションを構成できるようになりました。
public IActionResult Post([FromBody(EmptyBodyBehavior = EmptyBodyBehavior.Allow)]
MyModel model)
{
...
}
その他の機能強化
ASP.NET Core アセンブリに Null 許容の注釈を適用する作業が開始されました。 .NET 5 フレームワークの一般的なパブリック API サーフェイスのほとんどに注釈が付けられる予定です。
Startup クラスのアクティブ化を制御する
Startup
クラスのアクティブ化を制御するためのファクトリ メソッドをアプリで提供できるようにする、新しい UseStartup オーバーロードが追加されました。 Startup
クラスのアクティブ化の制御は、ホストと共に初期化される Startup
に追加のパラメーターを渡す場合に便利です。
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
を実行します。- ツールによってアプリのリビルド、再起動、再読み込みを処理しながら、コードの変更に集中します。
コンソール ロガー フォーマッタ
Microsoft.Extensions.Logging
ライブラリのコンソール ログ プロバイダーが改善されました。 開発者は、カスタム ConsoleFormatter
を実装して、コンソール出力の書式設定と色付けを完全に制御できるようになりました。 フォーマッタ API により、VT-100 エスケープ シーケンスのサブセットを実装することによって、豊富な書式設定が可能になります。 VT-100 は、最新のターミナルのほとんどでサポートされています。 コンソール ロガーでは、サポートされていないターミナルでエスケープ シーケンスを解析できるため、開発者はすべてのターミナル用に 1 つのフォーマッタを作成できます。
JSON コンソール ロガー
カスタム フォーマッタのサポートに加えて、構造化された JSON ログをコンソールに出力する組み込みの JSON フォーマッタも追加されました。 次のコードは、既定のロガーから JSON に切り替える方法を示しています。
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 形式になります。
{
"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}"
}
}
ASP.NET Core