Question 1

.NET 10.0.11 に突然 libmsalruntime.so が含まれるようになり、ビルドサイズが 38 MB 増加するのはなぜですか?

Accepted Answer

これは、`Microsoft.EntityFrameworkCore.SqlServer` 10.0.11–10.0.13 で導入された推移的依存関係チェーンが原因です。このバージョンでは `Microsoft.Data.SqlClient` が 6.1.1 から 6.1.6 にアップグレードされています。SqlClient 6.1.6 は `Microsoft.Identity.Client.Broker` 4.84.2 に依存しており、それが `Microsoft.Identity.Client.NativeInterop` 0.20.6 を引き込みます。このパッケージには 38 MB の `libmsalruntime.so` が `runtimes/linux-x64/native` に同梱されています。パスは `dotnet nuget why Microsoft.Identity.Client.NativeInterop` で確認できます。回避策: プロジェクトで `Microsoft.Data.SqlClient` バージョン 7.1.1（以降）を明示的に参照してください。このバージョンにはこのネイティブ依存関係が含まれないため、`libmsalruntime.so` はビルド出力から消えます。EFCore.SqlServer は将来のリリースで SqlClient 7.1.1 にアップグレードされる予定であり、それにより手動でのオーバーライドなしに解決される見込みです。

Question 2

ASP.NET Core で UseStatusCodePagesWithReExecute を使用するとレート制限ポリシーが適用されないのはなぜですか?

Accepted Answer

これはミドルウェアの登録順序の問題です。`UseRateLimiter` が `UseStatusCodePagesWithReExecute` より前に登録されている場合、レートリミッターは再実行ブランチの外側に位置し、再実行されたエンドポイントのポリシーを評価しません。

修正方法 — ステータスコードページのミドルウェアをルーティングの前に、レートリミッターをルーティングの後に登録します:

```csharp
app.UseStatusCodePagesWithReExecute("/b");
app.UseRouting();
app.UseRateLimiter();
```

この順序では、再実行時にルーティングが再度実行され、レートリミッターもその対象に含まれるため、新しく選択されたエンドポイント(例: `/b`)を読み取り、新しいリースを取得し、残りの許可がない場合にリクエストを拒否します。注意: ステータスコードページのミドルウェアより前に配置されたミドルウェアは、再実行時に再度実行されません。

Question 3

.NET 11 で修正されている Blazor の再接続の問題を .NET 10 で修正する方法

Accepted Answer

.NET SDK バージョン 10.0.400 以降（8月11日リリース）にアップグレードしてください。当初 .NET 11 向けに行われた再接続の修正は、.NET 10 ブランチにバックポートされ、この SDK バージョンで出荷されました。更新後も一時停止/再開や再接続の問題が引き続き発生する場合は、dotnet/aspnetcore GitHub リポジトリで新しい issue を作成してください。

Question 4

MSAL を使用する Blazor WASM が、ログイン後に要求された ReturnUrl ではなくアプリのルートにリダイレクトされるのはなぜですか？

Accepted Answer

これは `Microsoft.Authentication.WebAssembly.Msal` 10.0.8〜10.0.12 におけるリグレッションです。`getUser` や `getAccessToken` などの同時呼び出しが、初期化が完了する前に `AuthenticationService.init` に入る可能性があり、2つの MSAL インスタンスが作成されてしまいます。最初のインスタンスが `sessionStorage` から保存された `returnUrl` を削除し、その後 2番目のインスタンスが状態なしでサインインを完了するため、Blazor は `Navigation.BaseUri` にフォールバックします。

修正方法: PR #69735 および #69736 を含むパッチ適用済みリリースにアップグレードしてください。パッチ適用済みバージョンがまだ利用できない場合は、一時的に最後に正常動作していたバージョンにダウングレードしてください。

```bash
dotnet add package Microsoft.Authentication.WebAssembly.Msal --version 10.0.7
```

根本的な修正では、初期化の Promise をキャッシュすることで、同時呼び出し元がそれぞれ個別に MSAL インスタンスを作成してリダイレクトの状態を消費するのではなく、同じ MSAL インスタンスを共有するようになります。

Question 5

カスタムの IOutputCachePolicy が、ASP.NET Core 10.0.9 にアップグレードした後、認証済みレスポンスをキャッシュしなくなったのはなぜですか？

Accepted Answer

これは ASP.NET Core 10.0.9 から少なくとも 10.0.12 までに存在するリグレッションです。`DefaultPolicy.ServeResponseAsync` が認証済みユーザーに対して `AllowCacheStorage = false` を設定するようになり、`CacheRequestAsync` でキャッシュを有効化したカスタムポリシーを上書きしてしまいます。

回避策: カスタムポリシーは既定のポリシーの後に実行されるため、カスタムポリシーの `ServeResponseAsync` でフラグを再設定してください:

```csharp
public ValueTask ServeResponseAsync(OutputCacheContext context, CancellationToken cancellationToken)
{
    if (context.HttpContext.User?.Identity?.IsAuthenticated == true)
    {
        context.AllowCacheStorage = true;
    }

return ValueTask.CompletedTask;
}
```

既存の `AllowCacheStorage = true` および `CacheRequestAsync` 内の有効期限と vary-by 設定はそのまま維持してください。この方法は、ユーザー間で共有しても安全な認証済みレスポンスにのみ使用し、ユーザー固有のデータに対しては適切な `CacheVaryByRules` を構成してください。

恒久対応: PR #69580 とそのバックポート（.NET 10 向けの #69725、.NET 11 向けの #69724）を含む ASP.NET Core リリースにアップグレードしてください。インストールされているランタイムは `dotnet --info` で確認してください。

aspnetcore

概要

README プレビュー

FAQ (5)

同类型项目

tensorflow

superpowers

everything-claude-code

flutter