[release/10.0] Source code updates from dotnet/dotnet #121366

dotnet-maestro · 2025-11-05T02:07:23Z

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: 74dc5d43-0b13-491a-b063-0f03b26d7664
Build: 20251104.4 (289521)
Date Produced: November 4, 2025 7:16:29 PM UTC
Commit: 8ee0cc0bbdbacfeb5b7e703909c9731ff75600f1
Commit Diff: 79c85d9...8ee0cc0
Branch: release/10.0.1xx

Updated Dependencies

From 5.0.0-2.25515.111 to 5.0.0-2.25554.104
- Microsoft.CodeAnalysis
- Microsoft.CodeAnalysis.Analyzers
- Microsoft.CodeAnalysis.CSharp
- Microsoft.Net.Compilers.Toolset
From 10.0.100 to 10.0.101
- Microsoft.CodeAnalysis.NetAnalyzers
- Microsoft.DotNet.ApiCompat.Task
From 10.0.0-beta.25515.111 to 10.0.0-beta.25554.104
- Microsoft.DotNet.Arcade.Sdk
- Microsoft.DotNet.Build.Tasks.Archives
- Microsoft.DotNet.Build.Tasks.Feed
- Microsoft.DotNet.Build.Tasks.Installers
- Microsoft.DotNet.Build.Tasks.Packaging
- Microsoft.DotNet.Build.Tasks.TargetFramework
- Microsoft.DotNet.Build.Tasks.Templating
- Microsoft.DotNet.Build.Tasks.Workloads
- Microsoft.DotNet.CodeAnalysis
- Microsoft.DotNet.GenAPI
- Microsoft.DotNet.GenFacades
- Microsoft.DotNet.Helix.Sdk
- Microsoft.DotNet.PackageTesting
- Microsoft.DotNet.RemoteExecutor
- Microsoft.DotNet.SharedFramework.Sdk
- Microsoft.DotNet.XliffTasks
- Microsoft.DotNet.XUnitExtensions
From 0.11.5-alpha.25515.111 to 0.11.5-alpha.25554.104
- Microsoft.DotNet.Cecil
From 2.9.3-beta.25515.111 to 2.9.3-beta.25554.104
- Microsoft.DotNet.XUnitAssert
- Microsoft.DotNet.XUnitConsoleRunner
From 10.0.0 to 10.0.1
- Microsoft.NET.Sdk.IL
- Microsoft.NETCore.App.Ref
- Microsoft.NETCore.ILAsm
- runtime.native.System.IO.Ports
- System.Reflection.Metadata
- System.Reflection.MetadataLoadContext
- System.Text.Json
From 10.0.100-rtm.25515.111 to 10.0.101-servicing.25554.104
- Microsoft.NET.Workload.Emscripten.Current.Manifest-10.0.100.Transport
From 7.0.0-rc.1611 to 7.0.0-rc.5504
- NuGet.Frameworks
- NuGet.Packaging
- NuGet.ProjectModel
- NuGet.Versioning
From 2.0.0 to 2.0.1
- System.CommandLine
From 10.0.0-prerelease.25527.1 to 10.0.0-prerelease.25506.2
- Microsoft.DotNet.XHarness.CLI
- Microsoft.DotNet.XHarness.TestRunners.Common
- Microsoft.DotNet.XHarness.TestRunners.Xunit

Associated changes in source repos

[[ commit created by automation ]]

…885e38181

Updated Dependencies: Microsoft.CodeAnalysis, Microsoft.CodeAnalysis.Analyzers, Microsoft.CodeAnalysis.CSharp, Microsoft.Net.Compilers.Toolset (Version 5.0.0-2.25515.111 -> 5.0.0-2.25554.104) Microsoft.CodeAnalysis.NetAnalyzers, Microsoft.DotNet.ApiCompat.Task (Version 10.0.100 -> 10.0.101) Microsoft.DotNet.Arcade.Sdk, Microsoft.DotNet.Build.Tasks.Archives, Microsoft.DotNet.Build.Tasks.Feed, Microsoft.DotNet.Build.Tasks.Installers, Microsoft.DotNet.Build.Tasks.Packaging, Microsoft.DotNet.Build.Tasks.TargetFramework, Microsoft.DotNet.Build.Tasks.Templating, Microsoft.DotNet.Build.Tasks.Workloads, Microsoft.DotNet.CodeAnalysis, Microsoft.DotNet.GenAPI, Microsoft.DotNet.GenFacades, Microsoft.DotNet.Helix.Sdk, Microsoft.DotNet.PackageTesting, Microsoft.DotNet.RemoteExecutor, Microsoft.DotNet.SharedFramework.Sdk, Microsoft.DotNet.XliffTasks, Microsoft.DotNet.XUnitExtensions (Version 10.0.0-beta.25515.111 -> 10.0.0-beta.25554.104) Microsoft.DotNet.Cecil (Version 0.11.5-alpha.25515.111 -> 0.11.5-alpha.25554.104) Microsoft.DotNet.XUnitAssert, Microsoft.DotNet.XUnitConsoleRunner (Version 2.9.3-beta.25515.111 -> 2.9.3-beta.25554.104) Microsoft.NET.Sdk.IL, Microsoft.NETCore.App.Ref, Microsoft.NETCore.ILAsm, runtime.native.System.IO.Ports, System.Reflection.Metadata, System.Reflection.MetadataLoadContext, System.Text.Json (Version 10.0.0 -> 10.0.1) Microsoft.NET.Workload.Emscripten.Current.Manifest-10.0.100.Transport (Version 10.0.100-rtm.25515.111 -> 10.0.101-servicing.25554.104) NuGet.Frameworks, NuGet.Packaging, NuGet.ProjectModel, NuGet.Versioning (Version 7.0.0-rc.1611 -> 7.0.0-rc.5504) System.CommandLine (Version 2.0.0 -> 2.0.1) Microsoft.DotNet.XHarness.TestRunners.Common, Microsoft.DotNet.XHarness.TestRunners.Xunit, Microsoft.DotNet.XHarness.CLI (Version 10.0.0-prerelease.25527.1 -> 10.0.0-prerelease.25506.2)

steveisok · 2025-11-05T18:55:38Z

@dotnet/runtime-infrastructure linker tests are failing with PackageReference System.Threading.AccessControl will not be pruned.. Are there supplemental changes coming that need to work their way through?

dotnet-maestro · 2025-11-06T02:04:06Z

Important

The source repository has received code changes from an opposite flow. Any additional codeflows into this PR may potentially result in lost changes.

Please continue with one of the following options:

Close or merge this PR and let the codeflow continue normally
Close or merge this PR and receive the new codeflow immediately by triggering the subscription:
darc trigger-subscriptions --id 74dc5d43-0b13-491a-b063-0f03b26d7664
Force-flow new changes into this PR at your own risk (some PR commits might be reverted):
darc trigger-subscriptions --force --id 74dc5d43-0b13-491a-b063-0f03b26d7664

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

…-a4a6-a82885e38181

akoeplinger · 2025-11-06T17:15:51Z

@ericstj ^

ericstj · 2025-11-06T17:50:04Z

@akoeplinger This hack should be removed, like you did in main. 2abf811

~~Interesting that it took this long for that change to be observed by Mono.Linker.Tests.csproj. Those must not actually be building against the live product.~~ Nevermind, I see why this just hit now. It was bugfix in RC2 that fixed the pruning data to include this package which moved down in 10.0. It does mean that these are building against SDK targeting pack instead of live built, which is probably an unfortunate design of this subset.

ericstj · 2025-11-06T21:05:44Z

Looks like this test is failing due to wrong RuntimeInformation.FrameworkDesciprtion. It would seem the validation build has a stable version but STABILIZE_PACKAGE_VERSION might not be set.

I grabbed a binlog and noticed -->
InformationalVersion = 10.0.1

This is happening because of this -->

runtime/Directory.Build.targets

Line 62 in b2842ae

    
           <InformationalVersion Condition="'$(InformationalVersion)' == '' and '$(PreReleaseVersionLabel)' == 'servicing'">$(ProductVersion)</InformationalVersion>

And this PR changed the PreReleaseVersionLabel to servicing.

What's our expectation here?
#83311 changed this behavior - which has been around since 8.0.

It looks like 9.0 servicing set both

runtime/eng/Versions.props

Lines 17 to 18 in 9c2fb4b

    
           <StabilizePackageVersion Condition="'$(StabilizePackageVersion)' == ''">true</StabilizePackageVersion> 
        
           <DotNetFinalVersionKind Condition="'$(StabilizePackageVersion)' == 'true'">release</DotNetFinalVersionKind>

While this is not set in 10.0

runtime/eng/Versions.props

Lines 18 to 19 in c1ad1c6

    
           <StabilizePackageVersion Condition="'$(StabilizePackageVersion)' == ''">false</StabilizePackageVersion> 
        
           <DotNetFinalVersionKind Condition="'$(StabilizePackageVersion)' == 'true'">release</DotNetFinalVersionKind>

So maybe that's what we should do here, that would fix these tests, since they use this to control the behavior. @mmitche @akoeplinger ?

steveisok · 2025-11-13T20:41:22Z

@ericstj @mmitche @akoeplinger ping on ^

mmitche · 2025-11-13T22:04:18Z

@ericstj The stabilization setting isn't controlled at the repo level in UB. It's essentially a pipeline parameter. Is it possible to avoid assumptions based on the servicing label?

The reason I ask is that we may still produce non-stable servicing builds, possibly for hotfixes.

…-a4a6-a82885e38181

ericstj · 2025-11-14T07:14:59Z

So right now, the product has the correct value (stable), it's just the tests that are wrong (assuming not stable). I'm guessing we want to preserve this, even for pre-release hotfixes - but that's up for debate.

Tests have behavior that differs by the value of DotNetFinalVersionKind

runtime/src/libraries/System.Runtime/tests/System.Runtime.InteropServices.RuntimeInformation.Tests/System.Runtime.InteropServices.RuntimeInformation.Tests.csproj

Line 8 in 04c4fe6

    
           <DefineConstants Condition="'$(DotNetFinalVersionKind)' != ''">$(DefineConstants);STABILIZE_PACKAGE_VERSION</DefineConstants>

While the product's behavior differs off of PreReleaseVersionLabel

runtime/Directory.Build.targets

Lines 61 to 63 in b2842ae

    
           <InformationalVersion Condition="'$(InformationalVersion)' == '' and '$(VersionSuffix)' == ''">$(ProductVersion)</InformationalVersion> 
        
           <InformationalVersion Condition="'$(InformationalVersion)' == '' and '$(PreReleaseVersionLabel)' == 'servicing'">$(ProductVersion)</InformationalVersion> 
        
           <InformationalVersion Condition="'$(InformationalVersion)' == '' and '$(VersionSuffix)' != ''">$(ProductVersion)-$(VersionSuffix)</InformationalVersion>

I shared those other properties to show how this was working before.

Maybe we just make the tests honor DotNetFinalVersionKind to fix this, and avoid those other intermediate properties. Separately folks can decide what they want the behavior to be for pre-release hotfixes.

…icing

ViktorHofer · 2025-11-14T07:38:09Z

Regarding pruning:

It does mean that these are building against SDK targeting pack instead of live built, which is probably an unfortunate design of this subset.

Note that even if those components build with the live targeting pack, work needs to be done in runtime to give the SDK the live PackageOverrides.txt for pruning. Filed #121611

akoeplinger · 2025-11-14T10:42:05Z

StabilizePackageVersion is no longer used since #116152.

I didn't look closely here but basically what the tests try to verify is that FrameworkDescription only contains the 10.0.0 version without the semver suffix to prevent regressing #93913

mmitche · 2025-11-18T23:54:48Z

@premun @dotnet/prodconsvcs

There hasn't been flow from runtime 10.0 to VMR in like 2 weeks...could this PR be the reason?

ericstj · 2025-11-18T23:57:24Z

More test failures around the new versioning --

WARNING failure message 'The command output did not contain expected result: '10.0.1-ci'
File Name: /private/tmp/helix/working/B4C4097D/w/9EEB0897/e/test_artifacts/l3b24wvh.dnp/HelloWorld/HelloWorld
Arguments:
Environment:
DOTNET_ROOT =
DOTNET_CLI_TELEMETRY_OPTOUT = 1
DOTNET_ROOT_X64 =
DOTNET_CLI_HOME = /tmp/helix/working/B4C4097D/w/9EEB0897/e/.dotnet
DOTNET_ROOT(x86) =
DOTNET_HOST_TRACE = 1
Exit Code: 0x0
StdOut:
Hello World!


.NET 10.0.1

It's like we didn't do readiness with PR validation?

mmitche · 2025-11-19T00:01:03Z

More test failures around the new versioning --

WARNING failure message 'The command output did not contain expected result: '10.0.1-ci'
File Name: /private/tmp/helix/working/B4C4097D/w/9EEB0897/e/test_artifacts/l3b24wvh.dnp/HelloWorld/HelloWorld
Arguments:
Environment:
DOTNET_ROOT =
DOTNET_CLI_TELEMETRY_OPTOUT = 1
DOTNET_ROOT_X64 =
DOTNET_CLI_HOME = /tmp/helix/working/B4C4097D/w/9EEB0897/e/.dotnet
DOTNET_ROOT(x86) =
DOTNET_HOST_TRACE = 1
Exit Code: 0x0
StdOut:
Hello World!


.NET 10.0.1

It's like we didn't do readiness with PR validation?

There was PR validation on the internal flow

ericstj · 2025-11-19T00:36:27Z

There was PR validation on the internal flow

Maybe we didn't test non-stable PR validation, or we did something different during readiness then we're doing now. Regardless, we have another set of host tests to fix here. I can give it a crack. cc @agocke

Looks like the value of this comes from here

runtime/src/installer/tests/Assets/Projects/HelloWorld/Program.cs

Line 17 in bf7fe1d

Console.WriteLine(RuntimeInformation.FrameworkDescription);

Tests are getting

runtime/src/installer/pkg/sfx/Microsoft.NETCore.App/Directory.Build.targets

Line 25 in bf7fe1d

Which is the package version.

So similar to before -- FrameworkDescription is InformationalVersion which has no suffix in servicing, but tests are assuming it should match the package version. There are many places where we use this same target / version value - not all are asserting that it should match FrameworkDescription so I'm inclined to just relax the test to only look for the 3-part version.

…-a4a6-a82885e38181

ericstj · 2025-11-19T15:02:28Z

A few more host tests failing, which I'll help fix. @akoeplinger have you looked at the other failures?

ericstj · 2025-11-21T02:22:21Z

@akoeplinger looks like JIT tests are something you looked at in main -- #121164 (comment). I ported your fix.

ericstj · 2025-11-21T17:23:18Z

So there are some networking failures, and some more version inconsistency failures (assuming prerelease vs not prerelease in servicing). This time in tracing/eventpipe tests.

0.4s: ClrProductVersion: "10.0.1-ci"
System.Exception: ClrProductVersion must match. Expected: "10.0.1", received: "10.0.1-ci"

runtime/src/tests/tracing/eventpipe/processinfo2/processinfo2.cs

Line 261 in 6eb2b9b

string expectedClrProductVersion = typeof(object).Assembly.GetCustomAttribute<AssemblyInformationalVersionAttribute>()?.InformationalVersion;

runtime/src/tests/tracing/eventpipe/processinfo3/processinfo3.cs

Line 271 in 6eb2b9b

Utils.Assert(expectedClrProductVersion.Equals(clrProductVersion), $"ClrProductVersion must match. Expected: \"{expectedClrProductVersion}\", received: \"{clrProductVersion}\"");

I think in this case we should make the ClrProductVersion sent on the pipe to not have the suffix - or make the test use something other than InformationalVersion to compare to.

RuntimeProductVersion is defined as $(Version)

runtime/eng/versioning.targets

Line 167 in 6eb2b9b

#define RuntimeProductVersion $(Version)

So this is more fallout from setting PreReleaseVersionLabel to servicing without setting StabalizePackageVersion.
#121366 (comment)

I've been plowing ahead assuming product behavior was correct (packages with version suffix, but informational version without), but this is the first time I'll need to adjust the product. I'll try making this fix and hopefully nothing else breaks.

What do we want?

Previous releases in servicing:

Always built with stable versioning. Packages + InformationalVersion + FrameworkDescription

Currently in 10.0:

No longer use stable versioning in non-stable builds. Packages get -servicing suffix (or -ci in CI builds). InformationalVersion+FrameworkDescription currently refelects the stable versioning.

My thinking was that this was intentional because @mmitche mentioned we might want to share pre-release servicing builds - which we might want to look like the real servicing build in all ways but the suffix.

@mmitche @richlander @jkotas @ViktorHofer -- what do you all think? This is primarily about the behavior of pre-release servicing builds.

…kage)Version

ViktorHofer · 2025-11-21T20:15:06Z

Correct, this behavioral change was intentional. We don't stabilize at the repo level anymore. Instead, we flow the configuration for that in as an input parameter to the repo build in the VMR.

We don't want individual repos to stabilize as that's costly when publishing packages as that requires a dedicated feed, etc.

dotnet-maestro bot added 3 commits November 5, 2025 02:07

Backflow from https://github.com/dotnet/dotnet / 8ee0cc0 build 289521

ddb80d6

[[ commit created by automation ]]

Merge release/10.0 into darc-release/10.0-dff90b19-95ba-456f-a4a6-a82…

4361470

…885e38181

github-actions bot added the area-codeflow for labeling automated codeflow label Nov 5, 2025

Merge branch 'release/10.0' into darc-release/10.0-dff90b19-95ba-456f…

c21d01c

…-a4a6-a82885e38181

Remove System.Threading.AccessControl package reference

c1ad1c6

ericstj requested a review from marek-safar as a code owner November 6, 2025 17:48

dotnet-policy-service bot added the linkable-framework Issues associated with delivering a linker friendly framework label Nov 6, 2025

Merge branch 'release/10.0' into darc-release/10.0-dff90b19-95ba-456f…

d7235aa

…-a4a6-a82885e38181

Make RuntimeInformation tests expect stable framework version in serv…

2ae0c99

…icing

This was referenced Nov 14, 2025

[browser] HalfTests.ExplicitConversion_FromSingle failing due to NaN != NaN #103347

Open

Unable to pull image from mcr.microsoft.com #117164

Open

Update SdkVersionForWorkloadTesting

b5c8c90

Don't use pre-release version when testing FrameworkDescription

f49ce51

build-analysis bot mentioned this pull request Nov 19, 2025

Sometimes the helix SDK uses GetWorkItemsAsync when workitems aren't done processing. dotnet/dnceng#6011

Open

3 tasks

Merge branch 'release/10.0' into darc-release/10.0-dff90b19-95ba-456f…

8bd3613

…-a4a6-a82885e38181

ericstj and others added 3 commits November 19, 2025 08:03

Make host tests more granular on version.

83f6c63

Update SdkVersionForWorkloadTesting

41b18de

Revert resource name lookup change in BenchmarksGame

a309061

build-analysis bot mentioned this pull request Nov 21, 2025

[QUIC] Sporadic long running tests #119763

Open

Make RuntimeProductVersion match InformationalVersion instead of (Pac…

eb69b37

…kage)Version

[release/10.0] Source code updates from dotnet/dotnet #121366

Are you sure you want to change the base?

[release/10.0] Source code updates from dotnet/dotnet #121366

Conversation

dotnet-maestro bot commented Nov 5, 2025

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

Associated changes in source repos

Uh oh!

steveisok commented Nov 5, 2025

Uh oh!

dotnet-maestro bot commented Nov 6, 2025

Uh oh!

akoeplinger commented Nov 6, 2025

Uh oh!

ericstj commented Nov 6, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ericstj commented Nov 6, 2025

Uh oh!

steveisok commented Nov 13, 2025

Uh oh!

mmitche commented Nov 13, 2025

Uh oh!

ericstj commented Nov 14, 2025

Uh oh!

ViktorHofer commented Nov 14, 2025

Uh oh!

akoeplinger commented Nov 14, 2025

Uh oh!

mmitche commented Nov 18, 2025

Uh oh!

ericstj commented Nov 18, 2025

Uh oh!

mmitche commented Nov 19, 2025

Uh oh!

ericstj commented Nov 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ericstj commented Nov 19, 2025

Uh oh!

ericstj commented Nov 21, 2025

Uh oh!

ericstj commented Nov 21, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What do we want?

Previous releases in servicing:

Currently in 10.0:

Uh oh!

ViktorHofer commented Nov 21, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

ericstj commented Nov 6, 2025 •

edited

Loading

ericstj commented Nov 19, 2025 •

edited

Loading

ericstj commented Nov 21, 2025 •

edited

Loading