Update to Unified Build controls #38506
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Generally changes DotNetBuildFromSource -> DotNetBuildSourceOnly. Removes some usages in places where TFM filtering will do the job in place of explicit per-project filtering. Change the Microsoft.Build logic to support building the VMR against minimumMSBuildVersion in non-source-only modes.
|
Currently in testing. Hold please. |
|
Should resolve #27562 and repo changes necessary for dotnet/source-build#4031 |
ViktorHofer
reviewed
Feb 5, 2024
ViktorHofer
reviewed
Feb 5, 2024
ViktorHofer
reviewed
Feb 5, 2024
ViktorHofer
approved these changes
Feb 5, 2024
marcpopMSFT
reviewed
Feb 5, 2024
marcpopMSFT
reviewed
Feb 5, 2024
| modes or normal modes. In normal modes we use MicrosoftBuildMinimumVersion, otherwise | ||
| we use MicrosoftBuildVersion. Note: This is not abstracted in Versions.props because source-only | ||
| modes will import a version override file after Versions.props. --> | ||
| <ItemGroup Condition="'$(DotNetBuildSourceOnly)' == 'true'"> |
There was a problem hiding this comment.
@rainersigwald I think this maintains the same split versions between source build and not as before but I figure someone from msbuild should double check that.
There was a problem hiding this comment.
@dotnet/kitten ? I can look at some point but am out sick.
There was a problem hiding this comment.
Yeah, intention was to maintain the split versions. When building in MSFT mode, it should maintain the same behavior as the repo in isolation.
There was a problem hiding this comment.
The key bit is that I changed the way the split versions are maintained so that it works with non-SB VMR builds.
Co-authored-by: Viktor Hofer <viktor.hofer@microsoft.com>
ViktorHofer
approved these changes
Feb 7, 2024
|
Merging to get these fixes into the VMR for unified build. If there's additional feedback we can address that in a follow-up. |
rainersigwald
added a commit
that referenced
this pull request
May 1, 2024
MSBuild references were changed in #38506 to use MSBuildMinimumVersion in all non-source-build scenarios, but that's not necessary: the SDK will deliver the latest .NET MSBuild and use it for all CLI-driven builds. Using the old version broke some tests because of a mismatch between newer targets and the old engine that was being used to execute tests. Instead, split the reference based on the TF of the project that is building: for `net472`, use the minimum version if available, but for `$(SdkTargetFramework)` always use the latest.
v-wuzhai
pushed a commit
that referenced
this pull request
May 6, 2024
MSBuild references were changed in #38506 to use MSBuildMinimumVersion in all non-source-build scenarios, but that's not necessary: the SDK will deliver the latest .NET MSBuild and use it for all CLI-driven builds. Using the old version broke some tests because of a mismatch between newer targets and the old engine that was being used to execute tests. Instead, split the reference based on the TF of the project that is building: for `net472`, use the minimum version if available, but for `$(SdkTargetFramework)` always use the latest.
marcpopMSFT
pushed a commit
that referenced
this pull request
May 14, 2024
MSBuild references were changed in #38506 to use MSBuildMinimumVersion in all non-source-build scenarios, but that's not necessary: the SDK will deliver the latest .NET MSBuild and use it for all CLI-driven builds. Using the old version broke some tests because of a mismatch between newer targets and the old engine that was being used to execute tests. Instead, split the reference based on the TF of the project that is building: for `net472`, use the minimum version if available, but for `$(SdkTargetFramework)` always use the latest.
Forgind
pushed a commit
to Forgind/sdk
that referenced
this pull request
May 14, 2024
MSBuild references were changed in dotnet#38506 to use MSBuildMinimumVersion in all non-source-build scenarios, but that's not necessary: the SDK will deliver the latest .NET MSBuild and use it for all CLI-driven builds. Using the old version broke some tests because of a mismatch between newer targets and the old engine that was being used to execute tests. Instead, split the reference based on the TF of the project that is building: for `net472`, use the minimum version if available, but for `$(SdkTargetFramework)` always use the latest.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Generally changes DotNetBuildFromSource -> DotNetBuildSourceOnly. Removes some usages in places where TFM filtering will do the job in place of explicit per-project filtering. Change the Microsoft.Build logic to support building the VMR against minimumMSBuildVersion in non-source-only modes.