[main] Source code updates from dotnet/dotnet by dotnet-maestro[bot] · Pull Request #123386 · dotnet/runtime

dotnet-maestro · 2026-01-20T16:38:13Z

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: f7901f87-9f24-40d6-9bc1-564863937237
Build: 20260119.3 (297900)
Date Produced: January 19, 2026 7:04:17 PM UTC
Commit: adf42f5dcec99a409a6f63355f5b52147bfaf043
Commit Diff: bac6980...adf42f5
Branch: main

Updated Dependencies

From 5.4.0-2.26065.101 to 5.4.0-2.26069.103
- Microsoft.CodeAnalysis
- Microsoft.CodeAnalysis.Analyzers
- Microsoft.CodeAnalysis.CSharp
- Microsoft.Net.Compilers.Toolset
From 11.0.100-alpha.1.26065.101 to 11.0.100-preview.1.26069.103
- Microsoft.CodeAnalysis.NetAnalyzers
- Microsoft.DotNet.ApiCompat.Task
- Microsoft.NET.Workload.Emscripten.Current.Manifest-11.0.100.Transport
From 11.0.0-beta.26065.101 to 11.0.0-beta.26069.103
- 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.26065.101 to 0.11.5-preview.26069.103
- Microsoft.DotNet.Cecil
From 2.9.3-beta.26065.101 to 2.9.3-beta.26069.103
- Microsoft.DotNet.XUnitAssert
- Microsoft.DotNet.XUnitConsoleRunner
From 11.0.0-alpha.1.26065.101 to 11.0.0-preview.1.26069.103
- 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 7.3.0-preview.1.6601 to 7.3.0-preview.1.7003
- NuGet.Frameworks
- NuGet.Packaging
- NuGet.ProjectModel
- NuGet.Versioning
From 3.0.0-alpha.1.26065.101 to 3.0.0-preview.1.26069.103
- System.CommandLine
From 11.0.0-alpha.1.25628.1 to 11.0.0-alpha.1.26061.1
- runtime.linux-arm64.Microsoft.NETCore.Runtime.Wasm.Node.Transport
- runtime.linux-musl-arm64.Microsoft.NETCore.Runtime.Wasm.Node.Transport
- runtime.linux-musl-x64.Microsoft.NETCore.Runtime.Wasm.Node.Transport
- runtime.linux-x64.Microsoft.NETCore.Runtime.Wasm.Node.Transport
- runtime.osx-arm64.Microsoft.NETCore.Runtime.Wasm.Node.Transport
- runtime.osx-x64.Microsoft.NETCore.Runtime.Wasm.Node.Transport
- runtime.win-arm64.Microsoft.NETCore.Runtime.Wasm.Node.Transport
- runtime.win-x64.Microsoft.NETCore.Runtime.Wasm.Node.Transport

Associated changes in source repos

Diff the source with this PR branch

darc vmr diff --name-only https://github.com/dotnet/dotnet:adf42f5dcec99a409a6f63355f5b52147bfaf043..https://github.com/dotnet/runtime:darc-main-f7b01ba7-7db3-41b6-a678-1a49970ee930

[[ commit created by automation ]]

dotnet-maestro · 2026-01-21T02:06:23Z

Important

While this PR was open, the source repository has received code changes from this repository (an opposite codeflow merged).
To avoid complex conflicts, the codeflow cannot continue until this PR is closed or merged.

You can continue with one of the following options:

Ignore this and merge this PR as usual without waiting for the new changes.
Once merged, Maestro will create a new codeflow PR with the new changes.
Close this PR and wait for Maestro to open a new one with old and new changes included.
You will lose any manual changes made in this PR.
You can also manually trigger the new codeflow right away by running:
```
darc trigger-subscriptions --id f7901f87-9f24-40d6-9bc1-564863937237
```
Force a codeflow into this PR at your own risk if you want the new changes.
User commits made to this PR might be reverted.
```
darc trigger-subscriptions --id f7901f87-9f24-40d6-9bc1-564863937237 --force
```

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

lewing · 2026-01-21T16:08:56Z

@kotlarmilos please take a look at the swift errors

❌EXEC(0,0): error : /var/folders/kg/7q73ww8s3llgyl61c9z_j5g40000gn/C/clang/ModuleCache/2IS156K4ZHICY/Foundation-3EJO22UA1F2B1.pcm: No such file or directory
❌EXEC(0,0): error : /var/folders/kg/7q73ww8s3llgyl61c9z_j5g40000gn/C/clang/ModuleCache/2IS156K4ZHICY/_SwiftConcurrencyShims-2EK7503T0009Z.pcm: No such file or directory

lewing · 2026-01-21T18:04:13Z

@maraf lots of this on the wasm side

        [] /root/helix/work/workitem/e/wbtartifacts/AppSettingsTest_Debug_False_53n2zdet_rhj_鿀蜒枛遫䡫煉/LazyLibrary/LazyLibrary.csproj : error NU1102: Unable to find package Microsoft.NETCore.App.Runtime.browser-wasm with version (= 11.0.0-preview.1.26069.103) [/root/helix/work/workitem/e/wbtartifacts/AppSettingsTest_Debug_False_53n2zdet_rhj_鿀蜒枛遫䡫煉/App/WasmBasicTestApp.csproj]
        [] /root/helix/work/workitem/e/wbtartifacts/AppSettingsTest_Debug_False_53n2zdet_rhj_鿀蜒枛遫䡫煉/LazyLibrary/LazyLibrary.csproj : error NU1102:   - Found 27 version(s) in dotnet-public [ Nearest version: 6.0.0-preview.3.21201.4 ] [/root/helix/work/workitem/e/wbtartifacts/AppSettingsTest_Debug_False_53n2zdet_rhj_鿀蜒枛遫䡫煉/App/WasmBasicTestApp.csproj]
        [] /root/helix/work/workitem/e/wbtartifacts/AppSettingsTest_Debug_False_53n2zdet_rhj_鿀蜒枛遫䡫煉/LazyLibrary/LazyLibrary.csproj : error NU1102:   - Found 0 version(s) in nuget-local [/root/helix/work/workitem/e/wbtartifacts/AppSettingsTest_Debug_False_53n2zdet_rhj_鿀蜒枛遫䡫煉/App/WasmBasicTestApp.csproj]
        [] /root/helix/work/workitem/e/wbtartifacts/AppSettingsTest_Debug_False_53n2zdet_rhj_鿀蜒枛遫䡫煉/LazyLibrary/LazyLibrary.csproj : error NU1102:   - Found 0 version(s) in /root/helix/work/workitem/e/dotnet-latest/library-packs [/root/helix/work/workitem/e/wbtartifacts/AppSettingsTest_Debug_False_53n2zdet_rhj_鿀蜒枛遫䡫煉/App/WasmBasicTestApp.csproj]
        [] /root/helix/work/workitem/e/wbtartifacts/AppSettingsTest_Debug_False_53n2zdet_rhj_鿀蜒枛遫䡫煉/LazyLibrary/LazyLibrary.csproj : error NU1102:   - Found 0 version(s) in dotnet10 [/root/helix/work/workitem/e/wbtartifacts/AppSettingsTest_Debug_False_53n2zdet_rhj_鿀蜒枛遫䡫煉/App/WasmBasicTestApp.csproj]
        [] /root/helix/work/workitem/e/wbtartifacts/AppSettingsTest_Debug_False_53n2zdet_rhj_鿀蜒枛遫䡫煉/LazyLibrary/LazyLibrary.csproj : error NU1102:   - Found 0 version(s) in dotnet11 [/root/helix/work/workitem/e/wbtartifacts/AppSettingsTest_Debug_False_53n2zdet_rhj_鿀蜒枛遫䡫煉/App/WasmBasicTestApp.csproj]
        [] /root/helix/work/workitem/e/wbtartifacts/AppSettingsTest_Debug_False_53n2zdet_rhj_鿀蜒枛遫䡫煉/LazyLibrary/LazyLibrary.csproj : error NU1102:   - Found 0 version(s) in dotnet8 [/root/helix/work/workitem/e/wbtartifacts/AppSettingsTest_Debug_False_53n2zdet_rhj_鿀蜒枛遫䡫煉/App/WasmBasicTestApp.csproj]
        [] /root/helix/work/workitem/e/wbtartifacts/AppSettingsTest_Debug_False_53n2zdet_rhj_鿀蜒枛遫䡫煉/LazyLibrary/LazyLibrary.csproj : error NU1102:   - Found 0 version(s) in dotnet9 [/root/helix/work/workitem/e/wbtartifacts/AppSettingsTest_Debug_False_53n2zdet_rhj_鿀蜒枛遫䡫煉/App/WasmBasicTestApp.csproj]

lewing · 2026-01-21T18:13:20Z

@pavelsavara @maraf I assume this is related to #122495 now that the sdk has made it back

pavelsavara · 2026-01-21T18:16:00Z

@pavelsavara @maraf I assume this is related to #122495 now that the sdk has made it back

I hope the missing nuget would be created here dotnet/dotnet#4326

maraf · 2026-01-21T18:26:09Z

WBT should default to Mono, not CoreCLR. AppSettingsTests should not run on CoreCLR

vitek-karas · 2026-01-22T21:28:41Z

@rolfbjarne would you know what's up with the Swift errors, it sounds similar to something I've seen recently, but I can't remember (or find it).

rolfbjarne · 2026-01-22T23:06:10Z

@rolfbjarne would you know what's up with the Swift errors, it sounds similar to something I've seen recently, but I can't remember (or find it).

I haven't seen these errors before, so I don't have any idea what might be going on.

matouskozak · 2026-01-23T13:20:14Z

Just posting an update on what I found, maybe it can help someone find the real root cause of the failure:

I've been looking at the logs and it looks like it's using /Applications/Xcode_16.4.app but binlog shows that runtime thinks it's using XCode 17:

Apple clang version 17.0.0 %28clang-1700.0.13.5%29;Target: x86_64-apple-darwin24.6.0;Thread model:posix;InstalledDir: /Applications/Xcode_16.4.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin`

which causes the internal _XcodeVersion to be 17 not 16 (the regex is not that robust), which is wrong since there is no XCode 17).

This causes

runtime/src/coreclr/nativeaot/BuildIntegration/Microsoft.NETCore.Native.Unix.targets

Lines 285 to 287 in e741300

    
           <ItemGroup Condition="'$(UseLdClassicXCodeLinker)' != 'false' and '$(_IsApplePlatform)' == 'true'"> 
        
             <CustomLinkerArg Condition="'$(UseLdClassicXCodeLinker)' == 'true' or '$(_XcodeVersion)' == '15' or '$(_XcodeVersion)' == '16'" Include="-ld_classic" /> 
        
           </ItemGroup>

to not add the -ld_classic flag (+ there are a bunch of other places which do a similar check and add the flag). I tried local build with added -ld_classic and got a green build.

Note, the same _XcodeVersion=17 version can be found in logs on dotnet/runtime main which are green so there must have been another change which cause this to start failing. I'm trying to go over the commits but I haven't yet found what could cause this, something possible related is dotnet/sdk switched to osx.15 in dotnet/sdk@d25914c,

MichalStrehovsky · 2026-01-23T13:53:07Z

I've pulled down the binlog from the artifacts - yep, we're not passing -ld_classic, but we're not passing this in main either.

The failure is actually not from the clang/lld invocation. The failure comes from the subsequent:

        dsymutil  "/Users/runner/work/1/s/artifacts/bin/ILCompiler_publish/x64/Release/native/ilc" &&
        strip -no_code_signature_warning -x "/Users/runner/work/1/s/artifacts/bin/ILCompiler_publish/x64/Release/native/ilc"

I think the important part is

note: Linking a static library that was built with -gmodules, but the module cache was not found.  Redistributable static libraries should never be built with module debugging enabled.  The debug experience will be degraded due to incomplete debug information.

I think we're somehow ending up compiling the static libraries that native AOT ships with this -gmodules switch. Searching the internet for this message find many hits with some advice, but I don't have a mac to try any.

MichalStrehovsky · 2026-01-23T13:57:05Z

Here is what Sentry did to fix this: getsentry/sentry-cocoa#3800 if that helps.

rolfbjarne · 2026-01-23T14:58:07Z

which causes the internal _XcodeVersion to be 17 not 16 (the regex is not that robust), which is wrong since there is no XCode 17).

This is probably because this code assumes clang --version gives the Xcode version:

runtime/src/coreclr/nativeaot/BuildIntegration/Microsoft.NETCore.Native.Unix.targets

Lines 287 to 290 in fc7d401

    
           <Exec Command="clang --version" Condition="'$(_IsApplePlatform)' == 'true' and '$(UseLdClassicXCodeLinker)' == ''" IgnoreExitCode="true" StandardOutputImportance="Low" ConsoleToMSBuild="true"> 
        
             <Output TaskParameter="ExitCode" PropertyName="_XcodeVersionStringExitCode" /> 
        
             <Output TaskParameter="ConsoleOutput" PropertyName="_XcodeVersionString" /> 
        
           </Exec>

runtime/src/tasks/Crossgen2Tasks/Microsoft.NET.CrossGen.targets

Lines 623 to 626 in fc7d401

    
           <Exec Command="&quot;$(_AppleClang)&quot; --version" IgnoreExitCode="true" IgnoreStandardErrorWarningFormat="true" StandardOutputImportance="Low" ConsoleToMSBuild="true"> 
        
             <Output TaskParameter="ExitCode" PropertyName="_XcodeVersionStringExitCode" /> 
        
             <Output TaskParameter="ConsoleOutput" PropertyName="_XcodeVersionString" /> 
        
           </Exec>

which is very much not the case:

$ clang --version
Apple clang version 17.0.0 (clang-1700.6.3.2)

It looks like xcodebuild -version gives the Xcode version:

$ xcodebuild -version
Xcode 26.2
Build version 17C52

akoeplinger · 2026-01-23T16:42:39Z

@rolfbjarne this was added in #100190 to replace calling xcodebuild and I think at the time the Xcode and clang versions aligned (but still differed from upstream clang), i.e. I still see clang --version reporting 16.0 for Xcode 16.

It looks like clang didn't make the jump when Apple did the great version realigning to 26.

steveisok · 2026-01-27T03:14:33Z

I'm wondering if #120953 is the reason why we're seeing this? The failure is happening in ILCompiler/crossgen_publish where it's linking libraries from an already published runtime pack.

If true, I think we're going to have to ignore the error (if possible) and publish a new package with correct build tweaks.

steveisok · 2026-01-27T05:15:27Z

I think that might be it. Not sure the best way to ignore / change anything because ILCompiler_publish is using both the targets and the libraries from nuget and not the local repo.

MichalStrehovsky · 2026-01-27T06:23:46Z

I think that might be it. Not sure the best way to ignore / change anything because ILCompiler_publish is using both the targets and the libraries from nuget and not the local repo.

If we need a temporary unblock, I think setting StripSymbols property to false would work, since per the binlog this is from dsymutil/strip. Official builds might have a problem either the lack of dsym. Or we could use PublishSingleFile instead of PublishAot (this aasumes publishing cDAC doesn't run into this, since PublishSingleFile is not an option there).

I don't have a mac and I'm OOF Monday/Tuesday so I'm not going to try these, just trying to help.

kotlarmilos · 2026-01-27T10:37:58Z

I don’t think this is a runtime change, since we would otherwise be seeing it on main as well. I can reproduce the issue locally only on this PR, which suggests this is not an infra issue. I think I’ve identified a likely root cause in the SDK.

First, there is a new property group for the default PublishRuntimeIdentifier value in Microsoft.NET.RuntimeIdentifierInference.targets
dotnet/sdk@03f6df5 which sets PublishRuntimeIdentifier to NETCoreSdkPortableRuntimeIdentifier when PublishAot=true or PublishTrimmed:

<PropertyGroup Condition="'$(PublishRuntimeIdentifier)' == '' And '$(RuntimeIdentifier)' == '' And ...">
    <PublishRuntimeIdentifier>$(NETCoreSdkPortableRuntimeIdentifier)</PublishRuntimeIdentifier>
</PropertyGroup>

<PropertyGroup Condition="'$(PublishRuntimeIdentifier)' != '' And ...">
    <RuntimeIdentifiers>$(RuntimeIdentifiers);$(PublishRuntimeIdentifier)</RuntimeIdentifiers>
</PropertyGroup>

In the failing cases this resolves to osx-arm64 or osx-x64.

Second, ILCompiler pack processing was changed to iterate over RuntimeIdentifiers in ProcessFrameworkReferences.cs dotnet/sdk@9d42d7e and the
the condition was changed from:

if (EffectiveRuntimeIdentifier != null && !AotUseKnownRuntimePackForTarget) {

to

if (!AotUseKnownRuntimePackForTarget) {

As a result, ILCompiler packs are now processed for all RIDs in RuntimeIdentifiers, not only when EffectiveRuntimeIdentifier is set. I think for projects like ILCompiler_publish.csproj and crossgen2_publish.csproj pack processing now runs during build, not just during publish.

When the runtime is build with /p:PublishRuntimeIdentifier="" (or similar props like UseDefaultPublishRuntimeIdentifier), I can't get repro anymore. A potential fix would be to explicitly set PublishRuntimeIdentifier="" in the affected projects to avoid triggering the pack processing.

matouskozak · 2026-01-27T11:08:19Z

I tried reverting the #120953 locally but the failure persisted.

steveisok · 2026-01-27T11:24:13Z

I tried reverting the #120953 locally but the failure persisted.

That's not surprising because the problem is in the consumption of a nuget.

steveisok · 2026-01-27T12:00:15Z

I don’t think this is a runtime change, since we would otherwise be seeing it on main as well. I can reproduce the issue locally only on this PR, which suggests this is not an infra issue. I think I’ve identified a likely root cause in the SDK.

If we're not seeing it in main, that suggests we have been hiding the underlying issue.

I think we need two changes. The first is either turning off strip symbols temporarily or setting PublishRuntimeIdentifier="" so that the build can stop failing. The former seems more appealing to me. The second change I think is to switch from -g to -gline-tables-only in

runtime/src/native/libs/System.Security.Cryptography.Native.Apple/CMakeLists.txt

Line 92 in 871446d

    
           COMMAND xcrun swiftc -emit-object -static -parse-as-library -enable-library-evolution ${SWIFT_COMPILER_ERRORS_FLAG} -g ${SWIFT_OPTIMIZATION_FLAG} -runtime-compatibility-version none ${SWIFT_SDK_FLAG} -target ${SWIFT_COMPILER_TARGET} ${CMAKE_CURRENT_SOURCE_DIR}/pal_swiftbindings.swift -o pal_swiftbindings.o

I think that would prevent dsymutil from trying to chase down the pcm files.

@rolfbjarne @akoeplinger thoughts?

akoeplinger · 2026-01-27T13:09:47Z

hmm we've been discussing dotnet/sdk#52565 and dotnet/sdk#52674 in the 11.0 preview chat since Viktor found that there was an issue when rebootstrapping the VMR, maybe it's related

…gen2_publish to avoid failing the build looking for cached pcm files

steveisok · 2026-02-02T23:25:57Z

/ba-g Known issue not picked up by BA #123918

akoeplinger · 2026-02-04T18:35:53Z

src/coreclr/nativeaot/BuildIntegration/Microsoft.NETCore.Native.Unix.targets

    </ItemGroup>

-    <Exec Command="clang --version" Condition="'$(_IsApplePlatform)' == 'true' and '$(UseLdClassicXCodeLinker)' == ''" IgnoreExitCode="true" StandardOutputImportance="Low" ConsoleToMSBuild="true">
+    <Exec Command="xcodebuild -version" Condition="'$(_IsApplePlatform)' == 'true' and '$(UseLdClassicXCodeLinker)' == ''" IgnoreExitCode="true" StandardOutputImportance="Low" ConsoleToMSBuild="true">


@steveisok are we fine with keeping this change? it got changed a while ago because xcodebuild doesn't work when you only have the CommandLineTools package instead of full Xcode: #100189

> [!NOTE] > This is a codeflow update. It may contain both source code changes from > [the VMR](https://github.com/dotnet/dotnet) > as well as dependency updates. Learn more [here](https://github.com/dotnet/dotnet/tree/main/docs/Codeflow-PRs.md). This pull request brings the following source code changes [marker]: <> (Begin:f7901f87-9f24-40d6-9bc1-564863937237) ## From https://github.com/dotnet/dotnet - **Subscription**: [f7901f87-9f24-40d6-9bc1-564863937237](https://maestro.dot.net/subscriptions?search=f7901f87-9f24-40d6-9bc1-564863937237) - **Build**: [20260119.3](https://dev.azure.com/dnceng/internal/_build/results?buildId=2882688) ([297900](https://maestro.dot.net/channel/8298/github:dotnet:dotnet/build/297900)) - **Date Produced**: January 19, 2026 7:04:17 PM UTC - **Commit**: [adf42f5dcec99a409a6f63355f5b52147bfaf043](dotnet/dotnet@adf42f5) - **Commit Diff**: [bac6980...adf42f5](dotnet/dotnet@bac6980...adf42f5) - **Branch**: [main](https://github.com/dotnet/dotnet/tree/main) **Updated Dependencies** - From [5.4.0-2.26065.101 to 5.4.0-2.26069.103][1] - Microsoft.CodeAnalysis - Microsoft.CodeAnalysis.Analyzers - Microsoft.CodeAnalysis.CSharp - Microsoft.Net.Compilers.Toolset - From [11.0.100-alpha.1.26065.101 to 11.0.100-preview.1.26069.103][1] - Microsoft.CodeAnalysis.NetAnalyzers - Microsoft.DotNet.ApiCompat.Task - Microsoft.NET.Workload.Emscripten.Current.Manifest-11.0.100.Transport - From [11.0.0-beta.26065.101 to 11.0.0-beta.26069.103][1] - 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.26065.101 to 0.11.5-preview.26069.103][1] - Microsoft.DotNet.Cecil - From [2.9.3-beta.26065.101 to 2.9.3-beta.26069.103][1] - Microsoft.DotNet.XUnitAssert - Microsoft.DotNet.XUnitConsoleRunner - From [11.0.0-alpha.1.26065.101 to 11.0.0-preview.1.26069.103][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 [7.3.0-preview.1.6601 to 7.3.0-preview.1.7003][1] - NuGet.Frameworks - NuGet.Packaging - NuGet.ProjectModel - NuGet.Versioning - From [3.0.0-alpha.1.26065.101 to 3.0.0-preview.1.26069.103][1] - System.CommandLine - From [11.0.0-alpha.1.25628.1 to 11.0.0-alpha.1.26061.1](dotnet/dotnet@0f3a9cd...7a708d1) - runtime.linux-arm64.Microsoft.NETCore.Runtime.Wasm.Node.Transport - runtime.linux-musl-arm64.Microsoft.NETCore.Runtime.Wasm.Node.Transport - runtime.linux-musl-x64.Microsoft.NETCore.Runtime.Wasm.Node.Transport - runtime.linux-x64.Microsoft.NETCore.Runtime.Wasm.Node.Transport - runtime.osx-arm64.Microsoft.NETCore.Runtime.Wasm.Node.Transport - runtime.osx-x64.Microsoft.NETCore.Runtime.Wasm.Node.Transport - runtime.win-arm64.Microsoft.NETCore.Runtime.Wasm.Node.Transport - runtime.win-x64.Microsoft.NETCore.Runtime.Wasm.Node.Transport [marker]: <> (End:f7901f87-9f24-40d6-9bc1-564863937237) [1]: dotnet/dotnet@bac6980...adf42f5 [marker]: <> (Start:Footer:CodeFlow PR) ## Associated changes in source repos - dotnet/aspnetcore@30d4d50...03d43ac - dotnet/efcore@d52eb38...af8a90c - dotnet/razor@3eb8321...0152051 - dotnet/roslyn@e6f840b...a8d1f35 - dotnet/runtime@d120108...6afecd4 - dotnet/sdk@ec5f7d9...73e74e8 - dotnet/sourcelink@8573980...a4a7b91 - dotnet/templating@dba5ef6...c5d5136 <details> <summary>Diff the source with this PR branch</summary> ```bash darc vmr diff --name-only https://github.com/dotnet/dotnet:adf42f5dcec99a409a6f63355f5b52147bfaf043..https://github.com/dotnet/runtime:darc-main-f7b01ba7-7db3-41b6-a678-1a49970ee930 ``` </details> [marker]: <> (End:Footer:CodeFlow PR) --------- Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com> Co-authored-by: Larry Ewing <lewing@microsoft.com> Co-authored-by: Marek Fišera <mara@neptuo.com> Co-authored-by: Milos Kotlar <kotlarmilos@gmail.com> Co-authored-by: Steve Pfister <stpfiste@microsoft.com>

dotnet-maestro bot added 2 commits January 20, 2026 16:38

Backflow from https://github.com/dotnet/dotnet / adf42f5 build 297900

2e4e45f

[[ commit created by automation ]]

Update dependencies

5d16871

github-actions bot added the area-codeflow for labeling automated codeflow label Jan 20, 2026

dotnet-policy-service bot assigned dotnet-maestro[bot] Jan 20, 2026

lewing approved these changes Jan 20, 2026

View reviewed changes

lewing assigned kotlarmilos Jan 21, 2026

lewing assigned maraf Jan 21, 2026

lewing assigned pavelsavara Jan 21, 2026

lewing and others added 2 commits January 21, 2026 12:26

Merge branch 'main' into darc-main-f7b01ba7-7db3-41b6-a678-1a49970ee930

c8f0e82

UseMonoRuntime for library with RuntimeIdentifier=browser-wasm

6b250c7

maraf requested review from ilonatommy and maraf as code owners January 21, 2026 19:52

lewing unassigned pavelsavara and maraf Jan 21, 2026

maraf and others added 2 commits January 22, 2026 09:12

Disable LibraryMode test with WasmSDK=false

ca0d92e

Merge branch 'main' into darc-main-f7b01ba7-7db3-41b6-a678-1a49970ee930

1bee1d5

Update Swift compilation command to use line-tables-only for debugging

2f0d309

steveisok mentioned this pull request Jan 27, 2026

Remove StripSymbols workaround for macOS NativeAOT publish once Swift module debug fix is available #123687

Open

Temporarily set StripSymbols to false in ILCompiler_publish and cross…

25f2dcb

…gen2_publish to avoid failing the build looking for cached pcm files

steveisok requested a review from MichalStrehovsky as a code owner January 27, 2026 21:26

Add XUnitLogChecker to the list

d73c5f2

steveisok mentioned this pull request Feb 2, 2026

[nativeaot] BUG: File size is not in the expected range #123918

Closed

steveisok enabled auto-merge (squash) February 2, 2026 23:25

steveisok merged commit 39eb0d0 into main Feb 2, 2026
173 of 177 checks passed

steveisok deleted the darc-main-f7b01ba7-7db3-41b6-a678-1a49970ee930 branch February 2, 2026 23:26

akoeplinger reviewed Feb 4, 2026

View reviewed changes

dotnet-maestro bot mentioned this pull request Feb 5, 2026

[main] Source code updates from dotnet/runtime dotnet/dotnet#4680

Merged

kotlarmilos mentioned this pull request Feb 11, 2026

Re-enable symbol stripping for Apple platforms #124266

Open

Conversation

dotnet-maestro bot commented Jan 20, 2026

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

Associated changes in source repos

Uh oh!

dotnet-maestro bot commented Jan 21, 2026

Uh oh!

lewing commented Jan 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

lewing commented Jan 21, 2026

Uh oh!

lewing commented Jan 21, 2026

Uh oh!

pavelsavara commented Jan 21, 2026

Uh oh!

maraf commented Jan 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

vitek-karas commented Jan 22, 2026

Uh oh!

rolfbjarne commented Jan 22, 2026

Uh oh!

matouskozak commented Jan 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

MichalStrehovsky commented Jan 23, 2026

Uh oh!

MichalStrehovsky commented Jan 23, 2026

Uh oh!

rolfbjarne commented Jan 23, 2026

Uh oh!

akoeplinger commented Jan 23, 2026

Uh oh!

steveisok commented Jan 27, 2026

Uh oh!

steveisok commented Jan 27, 2026

Uh oh!

MichalStrehovsky commented Jan 27, 2026

Uh oh!

kotlarmilos commented Jan 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

matouskozak commented Jan 27, 2026

Uh oh!

steveisok commented Jan 27, 2026

Uh oh!

steveisok commented Jan 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

akoeplinger commented Jan 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

steveisok commented Feb 2, 2026

Uh oh!

Uh oh!

akoeplinger Feb 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

10 participants

lewing commented Jan 21, 2026 •

edited

Loading

maraf commented Jan 21, 2026 •

edited

Loading

matouskozak commented Jan 23, 2026 •

edited

Loading

kotlarmilos commented Jan 27, 2026 •

edited

Loading

steveisok commented Jan 27, 2026 •

edited

Loading

akoeplinger commented Jan 27, 2026 •

edited

Loading

akoeplinger Feb 4, 2026 •

edited

Loading