Skip to content

[main] Source code updates from dotnet/sdk - #10563

Open
dotnet-maestro[bot] wants to merge 10 commits into
mainfrom
darc-main-46e9a3cd-fc04-477e-ad9a-5658c59911ab
Open

dotnet-maestro[bot] wants to merge 10 commits into
mainfrom
darc-main-46e9a3cd-fc04-477e-ad9a-5658c59911ab

Conversation

@dotnet-maestro

@dotnet-maestro dotnet-maestro Bot commented Oct 30, 2026 •

Copy link
Copy Markdown
Contributor

Note

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

This pull request brings the following source code changes

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

Diff the source with this PR branch
darc vmr diff --name-only https://github.com/dotnet/sdk:14d3d468e4f2c4b631b593528a278cf9bacb7f17..https://github.com/dotnet/dotnet:darc-main-46e9a3cd-fc04-477e-ad9a-5658c59911ab

@dotnet-maestro

Copy link
Copy Markdown
Contributor Author

Caution

🚨 Action Required — Conflict detected

A conflict was detected when trying to update this PR with changes from build 338952 of https://github.com/dotnet/sdk/tree/4c425ca623e42d6ea86d2ec8e1b8b3834cc72e30.

The conflicts in the following files need to be manually resolved:

ℹ️ To resolve the conflicts, please follow these steps:

  1. Clone the current repository

    git clone https://github.com/dotnet/dotnet
    cd dotnet
  2. Make sure your darc is up-to-date
    (version 1.1.0-beta.26521.2 or higher)

    # Linux / MacOS
    ./eng/common/darc-init.sh
    # or on Windows
    .\eng\common\darc-init.ps1
  3. Run from repo's git clone and follow the instructions provided by the command to stage the conflict locally

    darc vmr resolve-conflict --subscription b80ccdd7-504a-4efb-b58b-d6480d0a64d9 

    This should apply the build 338952 with sources from 4c425ca

  4. Resolve the conflicts, commit & push the changes

  5. Once pushed, the Codeflow verification check will turn green.
    If not, a new build might have flown into the PR and you might need to run the command above again.

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

@dotnet-maestro

Copy link
Copy Markdown
Contributor Author

Note

PRs from original repository included in this codeflow update:

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

@azure-pipelines

Copy link
Copy Markdown
Azure Pipelines:
2 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

@dotnet-policy-service
dotnet-policy-service Bot requested a review from a team October 30, 2026 02:13
@akoeplinger
akoeplinger requested review from a team as code owners October 30, 2026 16:07
@dotnet-maestro

Copy link
Copy Markdown
Contributor Author

@dotnet-maestro

dotnet-maestro Bot commented Nov 3, 2026

Copy link
Copy Markdown
Contributor Author

Regenerate XLF with UpdateXlf to remove the repeated package source mapping resource key that fails CI localization validation.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
@dsplaisted

Copy link
Copy Markdown
Member

@dotnet/source-build It looks like this needs a re-bootstrap to bring in an MSBuild fix that should fix a packaging failure.

Can we re-bootstrap as needed or is there anything we need to wait for?

AI Analysis

Windows x86 packaging is failing due to a mismatch between the package cache used during restore and the one used during the subsequent build. In [build 1661044](https://dev.azure.com/dnceng-public/public/_build/results?buildId=1661044), Roslyn’s PackageReleasePackages target fails at BuildReleasePackages.targets(17,5):

error MSB4036: The "Microsoft.DotNet.Tools.UpdatePackageVersionTask" task was not found.

The binlog shows that restore generated package imports pointing to src\runtime\artifacts\.packages, while the build evaluates NuGetPackageRoot as src\roslyn\artifacts\.packages. The import that registers the packaging task is guarded by Exists, so it is silently skipped when the package is absent from the Roslyn cache.

I reproduced this failure pattern with CI’s exact bootstrap SDK, 12.0.100-alpha.1.26480.102. Multithreaded MSBuild’s TaskHost environment handling can replace the build’s virtual NUGET_PACKAGES value with its process-startup value. This matches dotnet/msbuild#15032, whose fix is present in the VMR sources but absent from the older bootstrap SDK.

The preferred resolution is to re-bootstrap onto an SDK containing that fix. Explicitly passing the intended cache as global RestorePackagesPath also avoids the failure in the reproducer, as does /mt:false; disabling node reuse alone does not. The full Windows x86 packaging leg still needs confirmation.

@mthalman

mthalman commented Nov 3, 2026

Copy link
Copy Markdown
Member

@dotnet/source-build It looks like this needs a re-bootstrap to bring in an MSBuild fix that should fix a packaging failure.

Can we re-bootstrap as needed or is there anything we need to wait for?

Looks like we have one pending: #10625
@ViktorHofer

@ViktorHofer

Copy link
Copy Markdown
Member

Yes, @akoeplinger is driving that. I'm just a reviewer :)

@akoeplinger

Copy link
Copy Markdown
Member

lol and I just noticed the rebootstrap is broken in part because it's missing some sdk change :) I think I can workaround that though.

@dotnet-maestro

dotnet-maestro Bot commented Nov 4, 2026

Copy link
Copy Markdown
Contributor Author

ProjectData's publish output ships NuGet.Versioning in the SDK layout. Keep transitive pinning disabled for regular builds, but enable it in source-only builds so the dependency resolves to the source-built version and has a matching symbol file.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
(cherry picked from commit b1872a2)
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 94493bfb-271a-49e3-b741-92f0337d8f59
@akoeplinger

akoeplinger commented Nov 4, 2026 •

Copy link
Copy Markdown
Member

The previous commit hit a test failure:

 Microsoft.DotNet.SourceBuild.Tests.SymbolsTests.VerifySdkSymbols
Assert.True() Failure
Expected: True
Actual:   False
   at Microsoft.DotNet.SourceBuild.Tests.SymbolsTests.VerifySdkSymbols() in /_/test/Microsoft.DotNet.SourceBuild.Tests/SymbolsTests.cs:line 65
   at System.Reflection.IntrinsicInvokeHelper.Instance_Void_0(IntPtr fn, Object obj, IntPtr* _, RuntimeType __)
   at System.Reflection.IntrinsicInvokeHelper.Invoke(InvokeState& state, InvokerStrategy& strategy, InvokeFunc_RefArgs& invokeFunc, MethodBase method, RuntimeType[] argumentTypes, Object obj, IntPtr* args, Boolean backwardsCompat)
   at System.Reflection.MethodBaseInvoker.InvokeWithSharedThunk(Object obj, IntPtr* args)
   at System.Reflection.MethodBaseInvoker.InvokeWithNoArgs(Object obj, BindingFlags invokeAttr)
Output:
Executing: tar xzf /__w/1/s/artifacts/assets/Release/dotnet-symbols-sdk-12.0.100-alpha.1-centos.10-x64.tar.gz -C /__w/1/s/artifacts/bin/Microsoft.DotNet.SourceBuild.Tests/Release/SymbolsTests/symbols
Did not find PDBs for the following SDK files:
/__w/1/s/artifacts/obj/extracted-dotnet-sdk/sdk/12.0.100-ci/ProjectData/NuGet.Versioning.dll

The missing symbol failure comes from tool_projectdata.csproj publishing an older NuGet.Versioning.dll whose matching PDB isn’t in the current source-build symbols. Despite being a layout helper, its PackageReference publishes runtime dependencies too; CopyBuildOutputToPublishDirectory=false only excludes the helper’s own assembly.

Transitive pinning was disabled in dotnet/sdk#56753 to avoid NU1109 errors caused by NuGet’s build-number wraparound, described in #9985. Main’s package versions no longer require that workaround, but the standalone SDK’s release/11.0.2xx branch still has the stale central pin.

I cherry-picked b1872a2 from #10468 to keep main and 11.0.2xx aligned: re-enable transitive pinning in source-only builds so ProjectData ships the current source-built dependency, while preserving regular-build behavior.

@dsplaisted @nagilson @ViktorHofer @mthalman I wonder if we need the NuGet.Versionining.dll in the ProjectData folder. I assume it could just use the one in the SDK root folder instead? looks like this is what e.g. Microsoft.NET.Build.Tasks already does:

<!-- These are loaded from the CLI's copy on .NET Core, we don't need to duplicate them on disk -->
<ItemGroup Condition="'$(TargetFrameworkIdentifier)' == '.NETCoreApp'">
<PackageReference Update="Microsoft.Extensions.DependencyModel" ExcludeAssets="Runtime" />
<PackageReference Update="Microsoft.NET.HostModel" ExcludeAssets="Runtime" />
<PackageReference Update="NuGet.ProjectModel" ExcludeAssets="Runtime" />
</ItemGroup>

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants