[automated] Merge branch 'release/9.0.3xx' => 'main'

[github-actions]

I detected changes in the release/9.0.3xx branch which have not been merged yet to main. I'm a robot and am configured to help you automatically keep main up to date, so I've opened this PR.

This PR merges commits made on release/9.0.3xx by the following committers:

• Forgind
• tmat
• edvilme
• v-wuzhai
• dotnet-maestro[bot]
• marcpopMSFT
• DustinCampbell
• invalid-email-address
• joeloff
• dotnet-bot
• baronfel
• Sergio0694
• kasperk81
• surayya-MS
• vseanreesermsft
• akoeplinger

Instructions for merging from UI

This PR will not be auto-merged. When pull request checks pass, complete this PR by creating a merge commit, not a squash or rebase commit.

If this repo does not allow creating merge commits from the GitHub UI, use command line instructions.

Instructions for merging via command line

Run these commands to merge this pull request from the command line.

git fetch
git checkout release/9.0.3xx
git pull --ff-only
git checkout main
git pull --ff-only
git merge --no-ff release/9.0.3xx

# If there are merge conflicts, resolve them and then run git merge --continue to complete the merge
# Pushing the changes to the PR branch will re-trigger PR validation.
git push https://github.com/dotnet/sdk HEAD:merge/release/9.0.3xx-to-main

or if you are using SSH

git push [email protected]:dotnet/sdk HEAD:merge/release/9.0.3xx-to-main

After PR checks are complete push the branch

git push

Instructions for resolving conflicts

⚠️ If there are merge conflicts, you will need to resolve them manually before merging. You can do this using GitHub or using the command line.

Instructions for updating this pull request

Contributors to this repo have permission update this pull request by pushing to the branch 'merge/release/9.0.3xx-to-main'. This can be done to resolve conflicts or make other changes to this pull request before it is merged.
The provided examples assume that the remote is named 'origin'. If you have a different remote name, please replace 'origin' with the name of your remote.

git fetch
git checkout -b merge/release/9.0.3xx-to-main origin/main
git pull https://github.com/dotnet/sdk merge/release/9.0.3xx-to-main
(make changes)
git commit -m "Updated PR with my changes"
git push https://github.com/dotnet/sdk HEAD:merge/release/9.0.3xx-to-main

or if you are using SSH

git fetch
git checkout -b merge/release/9.0.3xx-to-main origin/main
git pull [email protected]:dotnet/sdk merge/release/9.0.3xx-to-main
(make changes)
git commit -m "Updated PR with my changes"
git push [email protected]:dotnet/sdk HEAD:merge/release/9.0.3xx-to-main

Contact .NET Core Engineering (dotnet/dnceng) if you have questions or issues.
Also, if this PR was generated incorrectly, help us fix it. See https://github.com/dotnet/arcade/blob/main/.github/workflows/scripts/inter-branch-merge.ps1.

[MiYanni]

@rainersigwald So, there is a build error with the version of System.Memory that was added in this change by @tmat . It causes the build to error because of this check which says to contact the MSBuild team about it.

[v-wuzhai]

@Forgind The GivenWorkloadSearchWithComponentsItFindsHighestMatchingSet test failed. This test change comes from #45156. Could you take a look? Thanks!

System.Collections.Generic.KeyNotFoundException : The given key '10.0.103' was not present in the dictionary.

[v-wuzhai]

@dsplaisted @MiYanni Looks like there are a bunch of test failures in windows.amd64.vs2022.pre.scout.open. Could you take a look? Thanks!

warning NETSDK1224: ASP.NET Core framework assets are not supported for the target framework.

[dsplaisted]

@ericstj @rainersigwald @ViktorHofer We're getting failures in Full Framework that look like this:

obj\Debug\net10.0\staticwebassets.build.json MissingMethodException: Method not found: '!!0 System.Text.Json.JsonSerializer.Deserialize(System.ReadOnlySpan`1<Byte>, System.Text.Json.Serialization.Metadata.JsonTypeInfo`1<!!0>)'.
   at Microsoft.AspNetCore.StaticWebAssets.Tasks.StaticWebAssetsManifest.FromJsonBytes(Byte[] jsonBytes)
   at Microsoft.AspNetCore.StaticWebAssets.Tasks.ReadStaticWebAssetsManifestFile.Execute() in D:\git\dotnet-sdk-main\src\StaticWebAssetsSdk\Tasks\ReadStaticWebAssetsManifestFile.cs:line 37
 [d:\git\dotnet-sdk-main\artifacts\tmp\Debug\It_warns_with---EF769788\WebWithPublishProfile\WebWithPublishProfile.csproj]

Can you help us with this? It doesn't look like this merge changes the version of System.Text.Json that we compile against, though it does pin System.Buffers, System.Memory, and System.Threading.Tasks.Extensions.

[ViktorHofer]

I don't think that you can already unconditionally use these versions. VS hasn't picked those versions up yet: dotnet/msbuild#11038

Either downgrade to the previous versions (when not building from source) or make sure that desktop msbuild tasks use the older versions.

[ViktorHofer]

@dsplaisted I'm relatively sure that the above error that you posted is due to this dependency update. This manifests in a MissingMethodException as types from those packages are used in the public method signature: System.ReadOnlySpan.

[ericstj]

The rule we must follow on all .NETFramework tasks is:

1. Reference an assembly version <= the one in MSBuild and don't ship it. We'll benefit from MSBuild's bindingRedirects for unification.
2. Reference a higher assembly version than is in MSBuild and ship that version ourselves -- we cannot require bindingRedirects for any dependency that exchanges types.

As @ViktorHofer suggests - we shouldn't be upgrading these. We should remove the entries for these packages and keep all tasks in mode 1 above. Ideally we take special care in all task projects to segment what references we expect to come from MSBuild vs what's local to the task (ideally nothing).

[dsplaisted]

FYI @ericstj @ViktorHofer @tmat @rainersigwald @v-wuzhai I think I may have fixed the assembly mismatch issues with 9cf989b

Instead of pinning System.Buffers, System.Memory, and System.Threading.Tasks.Extensions for the whole repo, it references the "toolset" versions (the versions supplied by Visual Studio / Full Framework MSBuild) from the HotReload.Agent.PipeRpc project. This should avoid changing the versions of these packages that other projects use.

[marcpopMSFT]

The current 15m timeout is a bit low for the watch tests I think. We should probably just up that. @tmat suggestion on how long the watch work items should need? I wanted the timeout low enough to get dumps on arm64 if we could.

[MiYanni]

FYI @ericstj @ViktorHofer @tmat @rainersigwald @v-wuzhai I think I may have fixed the assembly mismatch issues with 9cf989b

Instead of pinning System.Buffers, System.Memory, and System.Threading.Tasks.Extensions for the whole repo, it references the "toolset" versions (the versions supplied by Visual Studio / Full Framework MSBuild) from the HotReload.Agent.PipeRpc project. This should avoid changing the versions of these packages that other projects use.

Was this the right fix? This PR was merged without confirmation.

[ericstj]

Sounds correct. I was discussing this with @dsplaisted in chat yesterday. SDK needs to be more careful about which dependencies it needs to be external. For those they really shouldn't be upgraded nor enabled for transitive pinning.