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

[github-actions]

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

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

• marcpopMSFT
• v-wuzhai
• SimonZhao888
• dotnet-maestro[bot]
• dtivel

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.1xx
git pull --ff-only
git checkout release/9.0.3xx
git pull --ff-only
git merge --no-ff release/9.0.1xx

# 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.1xx-to-release/9.0.3xx

or if you are using SSH

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

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.1xx-to-release/9.0.3xx'. 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.1xx-to-release/9.0.3xx origin/release/9.0.3xx
git pull https://github.com/dotnet/sdk merge/release/9.0.1xx-to-release/9.0.3xx
(make changes)
git commit -m "Updated PR with my changes"
git push https://github.com/dotnet/sdk HEAD:merge/release/9.0.1xx-to-release/9.0.3xx

or if you are using SSH

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

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.

[v-wuzhai]

Hi @marcpopMSFT, @MiYanni

I did a quick experiment and noticed that test projects seem able to use version properties defined in Versions.props — even without directly importing it — as long as they include testAsset.props via:

<Import Project="$([MSBuild]::GetDirectoryNameOfFileAbove($(MSBuildThisFileDirectory), testAsset.props))\testAsset.props" />

From what I can tell, this might be because testAsset.props indirectly brings in Versions.props, making those properties (like $(FSharpCoreXXXXX)) available to the test project.

Here's a screenshot showing a test project using a custom version property from Versions.props, and the build output confirming that it was picked up and used:

If this behavior is reliable, we might consider centralizing more (or all) test package versions in Versions.props. That could help:

• Reduce duplication of version strings across test projects
• Make version updates easier and more consistent
• Improve maintainability over time

Just a thought — it seems like a useful direction.