forked from dotnet/msbuild
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Propagate solution configuration information to project cache plugins (…
…dotnet#6738) Context Visual Studio has solution configurations and project configurations. A configuration is a (Configuration, Platform) tuple. A solution configuration defines a specific project configuration for each project in the solution. It's like a mapping from a solution configuration to a list of project configurations for each project. At any moment a single solution configuration is active in VS. When doing a real build in VS, the active solution configuration is propagated as global properties on each build request. Up until now I didn't have a clear understanding of this, therefore the project cache setup has a bug when building under VS: it does not propagate the solution configuration information to the plugin instance. This means that if the user selects a non-default solution configuration (or if the solution is more complicated and the default project configuration assignment is not straightforward), there will be a mismatch between the build requests issued by VS (reflecting the non-default solution configuration) and the state of the plugin (reflecting the default solution configuration). The mismatches end up as build failures because the plugin is unable to match an incoming build request to an existing quickbuild build node (build node graph is created from MSBuild's static graph) Changes Made Unfortunately MSBuild does not know what the active VS solution configuration is. So in this PR we parse the project configuration for each project from an XML that VS sets on each build request as a global property (however horrible the idea of that global property is, without it we could not have enabled the build-under-VS scenario). Previously, msbuild used the .sln file as the single entry-point to the plugin. Starting with this PR it creates one entry point for each project in the parsed XML, with its particular project configuration set as global properties. This makes the static graph inside the plugin instance match the solution configuration. These changes are in the VS workaround part of the code. Ideally, if VS passed in the project cache graph descriptor, it would have enough information to just use a single .sln based entrypoint and set the solution configuration on it. Maybe, one day ... The PR also removes TargetFramework from the entry points. VS sets an empty TargetFramework="" global properties on outerbuilds (because why not). If we don't remove it it leaks into the graph entry-points, which propagates TF="" to all nodes in the graph, messing them up. Testing Unit tests and manual testing. Notes The meat of the implementation is here: https://github.com/dotnet/msbuild/pull/6738/files#diff-ac47163cf1a4ff2fbd79d56e0cf79ce9636b6a8331dfa89dae3fe8d3547f7fb3R345
- Loading branch information
Showing
9 changed files
with
369 additions
and
58 deletions.
There are no files selected for viewing
Large diffs are not rendered by default.
Oops, something went wrong.
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
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
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
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
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
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
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
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