[dotnet-maestro]

Note

This is a codeflow update. It may contain both source code changes from
the VMR
as well as dependency updates. Learn more here.

This pull request brings the following source code changes

From https://github.com/dotnet/dotnet

• Subscription: 8348293c-6613-4077-9cb7-c977fb9a8e78
• Build: 20260915.1 (332127)
• Date Produced: September 15, 2026 3:28:12 PM UTC
• Commit: 939a1706111f6d91a1e95242fec39860e8d9cc60
• Commit Diff: fa5198e...939a170
• Branch: release/10.0.1xx

New Dependencies

• Added 10.0.0-beta.26465.101
  • Microsoft.DotNet.Helix.JobMonitor

Updated Dependencies

• From 10.0.13 to 10.0.13
  • dotnet-ef
  • Microsoft.Bcl.AsyncInterfaces
  • Microsoft.Bcl.Cryptography
  • Microsoft.Bcl.TimeProvider
  • Microsoft.EntityFrameworkCore
  • Microsoft.EntityFrameworkCore.Design
  • Microsoft.EntityFrameworkCore.InMemory
  • Microsoft.EntityFrameworkCore.Relational
  • Microsoft.EntityFrameworkCore.Sqlite
  • Microsoft.EntityFrameworkCore.SqlServer
  • Microsoft.EntityFrameworkCore.Tools
  • Microsoft.Extensions.Caching.Abstractions
  • Microsoft.Extensions.Caching.Memory
  • Microsoft.Extensions.Configuration
  • Microsoft.Extensions.Configuration.Abstractions
  • Microsoft.Extensions.Configuration.Binder
  • Microsoft.Extensions.Configuration.CommandLine
  • Microsoft.Extensions.Configuration.EnvironmentVariables
  • Microsoft.Extensions.Configuration.FileExtensions
  • Microsoft.Extensions.Configuration.Ini
  • Microsoft.Extensions.Configuration.Json
  • Microsoft.Extensions.Configuration.UserSecrets
  • Microsoft.Extensions.Configuration.Xml
  • Microsoft.Extensions.DependencyInjection
  • Microsoft.Extensions.DependencyInjection.Abstractions
  • Microsoft.Extensions.DependencyModel
  • Microsoft.Extensions.Diagnostics
  • Microsoft.Extensions.Diagnostics.Abstractions
  • Microsoft.Extensions.FileProviders.Abstractions
  • Microsoft.Extensions.FileProviders.Composite
  • Microsoft.Extensions.FileProviders.Physical
  • Microsoft.Extensions.FileSystemGlobbing
  • Microsoft.Extensions.Hosting
  • Microsoft.Extensions.Hosting.Abstractions
  • Microsoft.Extensions.Http
  • Microsoft.Extensions.Logging
  • Microsoft.Extensions.Logging.Abstractions
  • Microsoft.Extensions.Logging.Configuration
  • Microsoft.Extensions.Logging.Console
  • Microsoft.Extensions.Logging.Debug
  • Microsoft.Extensions.Logging.EventLog
  • Microsoft.Extensions.Logging.EventSource
  • Microsoft.Extensions.Logging.TraceSource
  • Microsoft.Extensions.Options
  • Microsoft.Extensions.Options.ConfigurationExtensions
  • Microsoft.Extensions.Options.DataAnnotations
  • Microsoft.Extensions.Primitives
  • Microsoft.NET.Runtime.MonoAOTCompiler.Task
  • Microsoft.NET.Runtime.WebAssembly.Sdk
  • Microsoft.NETCore.App.Ref
  • System.Collections.Immutable
  • System.Composition
  • System.Configuration.ConfigurationManager
  • System.Diagnostics.DiagnosticSource
  • System.Diagnostics.EventLog
  • System.Diagnostics.PerformanceCounter
  • System.DirectoryServices.Protocols
  • System.Formats.Asn1
  • System.Formats.Cbor
  • System.IO.Hashing
  • System.IO.Pipelines
  • System.Memory.Data
  • System.Net.Http.Json
  • System.Net.Http.WinHttpHandler
  • System.Net.ServerSentEvents
  • System.Numerics.Tensors
  • System.Reflection.Metadata
  • System.Resources.Extensions
  • System.Runtime.Caching
  • System.Security.Cryptography.Pkcs
  • System.Security.Cryptography.Xml
  • System.Security.Permissions
  • System.ServiceProcess.ServiceController
  • System.Text.Encodings.Web
  • System.Text.Json
  • System.Threading.AccessControl
  • System.Threading.Channels
  • System.Threading.RateLimiting
• From 10.0.13-servicing.26461.103 to 10.0.13-servicing.26465.101
  • Microsoft.Extensions.HostFactoryResolver.Sources
  • Microsoft.Internal.Runtime.AspNetCore.Transport
  • Microsoft.NETCore.BrowserDebugHost.Transport
  • Microsoft.NETCore.Platforms
• From 10.0.0-beta.26461.103 to 10.0.0-beta.26465.101
  • Microsoft.DotNet.Arcade.Sdk
  • Microsoft.DotNet.Build.Tasks.Archives
  • Microsoft.DotNet.Build.Tasks.Installers
  • Microsoft.DotNet.Build.Tasks.Templating
  • Microsoft.DotNet.Helix.Sdk
  • Microsoft.DotNet.RemoteExecutor
  • Microsoft.DotNet.SharedFramework.Sdk
• From 3.2.13 to 3.2.13
  • Microsoft.Web.Xdt
• From 7.0.3-rc.46203 to 7.0.3-rc.46601
  • NuGet.Frameworks
  • NuGet.Packaging
  • NuGet.Versioning

Associated changes in source repos

• 634a767...1489829
• dotnet/efcore@c38d599...d82f323
• dotnet/emsdk@8397e5d...48ac8b2
• dotnet/razor@11cb49a...ab9ebbd
• dotnet/roslyn@0ea4de6...61a9a48
• dotnet/runtime@c97b658...afcd4be
• dotnet/scenario-tests@e4fee26...7a3a313
• dotnet/sdk@2e59cac...dd99e0d
• dotnet/windowsdesktop@3495947...af261df
• dotnet/winforms@0320616...ef2a0b2
• dotnet/wpf@5f8bd22...9b3c29b

Diff the source with this PR branch

darc vmr diff --name-only https://github.com/dotnet/dotnet:939a1706111f6d91a1e95242fec39860e8d9cc60..https://github.com/dotnet/aspnetcore:darc-release/10.0-0d0303e2-242c-40ac-994d-b17246f1ea00

[dotnet-maestro]

Note

VMR PRs included in this codeflow update:

• [release/10.0.1xx] Source code updates from dotnet/aspnetcore dotnet#9192

💡 You may consult the FAQ for more information or tag @dotnet/prodconsvcs for assistance.

[dotnet-policy-service]

Auto-approving dependency update.

[akoeplinger]

@BrennanConroy the test failures look related to the changes, we're also seeing them in the 11.0 PR: #69256

Quick analysis from Copilot:

---

Yes—there’s a strong, direct connection to the IISMiddleware change. This looks like an outdated assertion in the shared test application, rather than broken WebSocket transport.

What changed

In src/Servers/IIS/IISIntegration/src/IISMiddleware.cs, the PR stops clearing IHttpMaxRequestBodySizeFeature.MaxRequestBodySize by default. Clearing it now requires the Microsoft.AspNetCore.Server.IISIntegration.ClearMaxRequestBodySize AppContext switch.

Previously, the out-of-process tests therefore always saw null, regardless of whether upgrading the connection changed the value.

Why these three tests fail together

All three endpoints call the same Upgrade(context) helper in Startup.WebSockets.cs. Immediately after upgrading, it asserts that the body-size limit is null:

// Upgrade the connection
Stream opaqueTransport = await upgradeFeature.UpgradeAsync();
Assert.Null(context.Features.Get<IHttpMaxRequestBodySizeFeature>().MaxRequestBodySize);

// Get the WebSocket object
var ws = WebSocket.CreateFromStream(opaqueTransport, isServer: true, subProtocol: null, keepAliveInterval: TimeSpan.FromMinutes(2));

Kestrel’s upgrade implementation doesn’t clear that property. Its getter still returns the configured value; upgrading instead makes the feature read-only (HttpProtocol.FeatureCollection.cs, lines 198–220 and 259–290).

The resulting sequence is:

1. IIS middleware now preserves the configured limit.
2. The connection upgrades.
3. The shared helper’s Assert.Null fails before creating the server-side WebSocket or sending any messages.

That explains the same failures under both IIS and IISExpress out-of-process hosting. It also predicts an assertion failure in the server logs, potentially surfaced as a connection-aborted/premature-close error on the client—not necessarily a request-body-too-large error.

An additional useful cross-check: AttemptCompressionWorks uses AcceptWebSocketAsync directly rather than this helper, so this particular assertion would not affect it (Startup.WebSockets.cs, lines 110–130).

Suggested fix

Make the shared helper assert the invariant both servers support—read-only after upgrade—rather than requiring the property to become null:

 Stream opaqueTransport = await upgradeFeature.UpgradeAsync();
-Assert.Null(context.Features.Get<IHttpMaxRequestBodySizeFeature>().MaxRequestBodySize);
+Assert.True(context.Features.Get<IHttpMaxRequestBodySizeFeature>().IsReadOnly);

[akoeplinger]

Ah just saw that the test issue was already fixed in #69187 (comment), @rokonec I assume we should cherry-pick that commit here and in the 11.0 PR?

@BrennanConroy why were the backports to 8.0/9.0 closed?

[BrennanConroy]

Because I thought the PR I was backporting was the test fix, not the whole change. We should cherry-pick the test fix into 8, 9, 10, and 11.

[wtgodbe]

Because I thought the PR I was backporting was the test fix, not the whole change. We should cherry-pick the test fix into 8, 9, 10, and 11.

Doing that now