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——该包在 runtimes/linux-x64/native 目录下附带了一个 38 MB 的 libmsalruntime.so 文件。你可以使用 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 10 中已在 .NET 11 中修复的 Blazor 重连问题？

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`，从而创建两个 MSAL 实例。第一个实例会从 `sessionStorage` 中移除已保存的 `returnUrl`；随后第二个实例在没有状态的情况下完成登录，导致 Blazor 回退到 `Navigation.BaseUri`。

修复方法：升级到包含 PR #69735 和 #69736 的已修补版本。如果已修补版本尚未发布，请暂时降级到上一个正常工作的版本：

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

底层修复通过缓存初始化 Promise，使并发调用方共享同一个 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;
}
```

保留 `CacheRequestAsync` 中现有的 `AllowCacheStorage = true` 以及过期时间和 vary-by 设置。请仅将此方法用于可安全跨用户共享的经过身份验证的响应；对于特定于用户的数据，请配置适当的 `CacheVaryByRules`。

永久修复：升级到包含 PR #69580 及其向后移植（.NET 10 对应 #69725，.NET 11 对应 #69724）的 ASP.NET Core 版本。使用 `dotnet --info` 验证已安装的运行时。

aspnetcore

项目简介

README 预览

常见问题 (5)

同类型项目

tensorflow

superpowers

everything-claude-code

flutter