Merge release/dev17.2 to release/dev17.3

[dotnet-bot]

This is an automatically generated pull request from release/dev17.2 into release/dev17.3.

Once all conflicts are resolved and all the tests pass, you are free to merge the pull request. 🐯

Troubleshooting conflicts

Identify authors of changes which introduced merge conflicts

Scroll to the bottom, then for each file containing conflicts copy its path into the following searches:

• https://github.com/dotnet/roslyn/find/release/dev17.2
• https://github.com/dotnet/roslyn/find/release/dev17.3

Usually the most recent change to a file between the two branches is considered to have introduced the conflicts, but sometimes it will be necessary to look for the conflicting lines and check the blame in each branch. Generally the author whose change introduced the conflicts should pull down this PR, fix the conflicts locally, then push up a commit resolving the conflicts.

Resolve merge conflicts using your local repo

Sometimes merge conflicts may be present on GitHub but merging locally will work without conflicts. This is due to differences between the merge algorithm used in local git versus the one used by GitHub.

git fetch --all
git checkout -t upstream/merges/release/dev17.2-to-release/dev17.3
git reset --hard upstream/release/dev17.3
git merge upstream/release/dev17.2
# Fix merge conflicts
git commit
git push upstream merges/release/dev17.2-to-release/dev17.3 --force

[ghost]

Auto-approval

[jaredpar]

@JoeRobich why are we merging on red here?

[JoeRobich]

The red CI is from a rolling build of 17.2 which is failing because an arcade update moved us to a new SDK. Arcade updates come in on the 17.0-vs-deps branch which does not run MSBuildWorkspace unit tests. 17.2 does and it requires that the NuGet version stay matched to what shipped in the pinned SDK. I opened #64840 to resolve this issue.

[jaredpar]

How does the rolling build show up here?

[JoeRobich]

So the GitHub merge bot creates a merge branch with the SHA of the branch that is merging up. Since we are not creating a merge commit by merging the target branch into the merge branch, the rolling runs with matching SHA show up in the PR. Also back-porting this test fix #64849.