Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[automated] Merge branch 'vs17.6' => 'main' #8693

Merged
merged 3 commits into from
Apr 26, 2023

Conversation

dotnet-maestro-bot
Copy link
Contributor

I detected changes in the vs17.6 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 vs17.6 by the following committers:

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.

merge button instructions

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 vs17.6
git pull --ff-only
git checkout main
git pull --ff-only
git merge --no-ff vs17.6

# 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-maestro-bot/msbuild HEAD:merge/vs17.6-to-main
or if you are using SSH
git push git@github.com:dotnet-maestro-bot/msbuild HEAD:merge/vs17.6-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/vs17.6-to-main'. This can be done to resolve conflicts or make other changes to this pull request before it is merged.

git checkout -b merge/vs17.6-to-main main
git pull https://github.com/dotnet-maestro-bot/msbuild merge/vs17.6-to-main
(make changes)
git commit -m "Updated PR with my changes"
git push https://github.com/dotnet-maestro-bot/msbuild HEAD:merge/vs17.6-to-main
or if you are using SSH
git checkout -b merge/vs17.6-to-main main
git pull git@github.com:dotnet-maestro-bot/msbuild merge/vs17.6-to-main
(make changes)
git commit -m "Updated PR with my changes"
git push git@github.com:dotnet-maestro-bot/msbuild HEAD:merge/vs17.6-to-main

Contact .NET Core Engineering if you have questions or issues.
Also, if this PR was generated incorrectly, help us fix it. See https://github.com/dotnet/arcade/blob/master/scripts/GitHubMergeBranches.ps1.

This reverts commit a93882f.

This is a temporary fix for dotnet#8684

The current plan is to revert dotnet#8275 in 17.6, as it caused some difficulties, and try to bring it back in 17.7 via dotnet#8685.

Summary

dotnet#8275 fixed a longstanding confusing and unfortunate behavior in MSBuild in which passing the Copy task a symlink as its destination would copy the source file onto the destination of the symlink rather than overwriting the symlink. Unfortunately, it also introduced a new issue in which copying a file onto itself could often just delete the file instead of copying anything. Customers reported this issue.

Customer Impact

Projects that copy a file onto itself using the Copy task without passing identical paths for source and destination instead delete the file without necessarily even logging an error.

Regression?
Yes, from dotnet#8275.

Testing

Unit tests and manually tested that the repro described in dotnet#8684 no longer works.

Risk
Minimal (straight revert of the commit that caused the bug)
---------

Co-authored-by: Forgind <Forgind@users.noreply.github.com>
…tnet#8625)

Summary
The for sln-based builds, the AssignProjectConfiguration task ends up using the Configuration and Platform defined in the sln rather than passing through the global properties from the referencing project or attempting to do dynamic platform negotiation. This change adds equivalent functionality to graph construction.

A concrete scenario this fixes for graph-based builds using an sln file is that most csproj define the "x86" platform while most vcxproj define "Win32". Previously for a graph build, if the csproj referenced the vcxproj, the platform passed to vcxproj would be x86, not Win32. Even worse, the vcxproj would be an entry point anyway, so it would double-build with both x86 AND Win32, which leads to race conditions.

Customer Impact
Microsoft-internal customer using sln-based builds will be able to opt-into graph builds

Regression?
No

Testing
Manual validation in the customer repo, as well as added unit tests

Risk
Low. Graph builds are a less-used feature, and this adds parity to what non-graph builds and VS-based builds do. It's unlikely that any behavioral change would be impactful due to those other scenarios presumably working for customers who may be using graph builds.
@dotnet-maestro-bot
Copy link
Contributor Author

This pull request has been updated.

This PR merges commits made on vs17.6 by the following committers:

@rainersigwald rainersigwald merged commit 0dbc421 into dotnet:main Apr 26, 2023
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