removing the dependency on IO.Redist from MSBuild GetPathToBuildToolsFile #11270
+7
−5
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.
Fixes https://developercommunity.visualstudio.com/t/Unable-to-locate-MSBuild-path-with-Lates/10824132
Work item (Internal use): https://devdiv.visualstudio.com/DevDiv/_workitems/edit/2343019
Related to:
microsoft/azure-pipelines-tasks#20734
Summary
The
Get-MsBuildPath
function used by the Azure DevopsMSBuild@1
task uses reflection to load a MSBuild function and then call it.MSBuild recently introduced (#9223) a dependency on
Microsoft.IO.Redist
in this codepath (it was used elsewhere in the assembly before).Microsoft.IO.Redist
depends onSystem.Memory
, which is in the MSBuild folder but at a higher version, so fails to load without binding redirects.This will cause the AzDO function to use a fallback location method that will load a very-old MSBuild (from .NET Framework 4) and the whole pipeline will most likely fail.
Customer Impact
Failure of Azure DevOps pipelines that use
MSBuild
orVSBuild
AzDO tasks VS 17.13.Regression?
Yes, from 17.12 and 17.13-preview.1, caused by #9223.
Testing
Manual testing with local versions of the AzDO script. VS experimental insertion for main branch has succeeded.
Risk
low: switching to directly use System.IO methods instead of wrappers that may use Microsoft.IO.Redist