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

[BUG]: MSBuild Task stopped finding MSBuild.exe file correctly #20734

Open
4 of 7 tasks
Ligtorn opened this issue Dec 16, 2024 · 0 comments
Open
4 of 7 tasks

[BUG]: MSBuild Task stopped finding MSBuild.exe file correctly #20734

Ligtorn opened this issue Dec 16, 2024 · 0 comments
Labels
Area: ABTT Akvelon Build Tasks Team area of work bug triage

Comments

@Ligtorn
Copy link

Ligtorn commented Dec 16, 2024

New issue checklist

Task name

MSBuild

Task version

All

Issue Description

I specified all task versions, as the problem is a combination of version used in assembly Microsoft.Build.Utilities.Core.dll and the powershell task

I have self hosted agent version 3.248.0 on my Azure DevOps account. it is hosted on a recently installed Win11 and I just have Visual Studio 2022 Enterprise Preview 17.13.0 Preview 2.0 and Visual Studio 2022 community edition Version 17.12.3 (Non Preview) installed. When I run a build against that build agent, it doesn’t pick up any of those editions, even though it detects them fine in the beginning, if you run it with debug=true

"C:\Agent\_work\_tasks\MSBuild_c6c4c611-aa2e-4a33-b606-5eaba2196824\1.246.3\node_modules\azure-pipelines-tasks-msbuildhelpers\tools\vswhere.exe" -version [17.0,18.0) -latest -format json
##[debug][
##[debug]  {
##[debug]    "installationName": "VisualStudioPreview/17.13.0-pre.2.0+35605.110",
##[debug]    "installationPath": "C:\\Program Files\\Microsoft Visual Studio\\2022\\Preview",
##[debug]    "installationVersion": "17.13.35605.110",
##[debug]    "displayName": "Visual Studio Enterprise 2022",
##[debug]    "updateDate": "2024-12-10T18:54:55.7707095Z",
##[debug]    "enginePath": "C:\\Program Files (x86)\\Microsoft Visual Studio\\Installer\\resources\\app\\ServiceHub\\Services\\Microsoft.VisualStudio.Setup.Service",
##[debug]    "resolvedInstallationPath": "C:\\Program Files\\Microsoft Visual Studio\\2022\\Preview",
##[debug]  }
##[debug]]

I have debugged the powershell task and found out that the issue comes from \MSBuild_c6c4c611-aa2e-4a33-b606-5eaba2196824\1.246.3\node_modules\azure-pipelines-tasks-msbuildhelpers\PathFunctions.ps1, it works if the script is execute from powershell core, but not when it is executed from powershell 5.1, which is that the task run is doing.

I did a bit more debugging and found out that this scripts dynamically loads the assembly “MSBuild\Current\Bin\Microsoft.Build.Utilities.Core.dll” from my Visual Studio 2022 Enterprise Preview 17.13.0 installation folder, and it calls the Microsoft.Build.Utilities.ToolLocationHelper method for finding the MSBuild.exe file for 64 bit edition. However inside Microsoft.Build.Utilities.Core.dll assembly recent changes have been done, so that will use a new assembly called MS. IO. Redist for doing a file.exists for the found msbuild.exe path. That method returns false, even when the path exists. it happens, because that assembly now requires System.Memory loaded and that doesn’t happen, hence it gets a FileLoadException exception, which gets swallowed and when it just returns false. This false value means that the agent code doesn’t think that the msbuild.exe path exists and attempts to find alternatives. This is better explained in this post dotnet/msbuild#9223 (comment)

This means as more and more agents are upgraded to newer visual studios editions with new dependency for MS.IO.Redist, it would lead to more and more issues and resolving to lower editions.

I suspect that the same issue is present in vsbuild task, but I haven’t tried it out

I don’t know if the agent tasks, needs some assembly redirects or manual load of System.Memory, or if the issue should be fixed in MS.IO.Redist, so I will let the experts look into that

I have made a simple powershell script which can show the issue, depending if you are running it in Windows Powershell or Powershell core. I am guessing that it works in Powershell Core, because System.Memory is already loaded

msbuildbug.ps1.txt

Environment type (Please select at least one enviroment where you face this issue)

  • Self-Hosted
  • Microsoft Hosted
  • VMSS Pool
  • Container

Azure DevOps Server type

dev.azure.com (formerly visualstudio.com)

Azure DevOps Server Version (if applicable)

No response

Operation system

Windows 11

Relevant log output

No error message, as it doesn't fail, just fallback to a very old MSBuild version 4.0, which is to old to build sdk style C# projects, so it fails in the build step.

"C:\Windows\Microsoft.NET\Framework64\v4.0.30319\msbuild.exe" "C:\agents\_work\1\s\Source\Soendergaard.SqlValidator.sln" /nologo /nr:false  /p:platform="Any CPU" /p:configuration="Release"
  Building solution configuration "Release|Any CPU".
##[debug]Processed: ##vso[task.logdetail parentid=;name=Soendergaard.SqlValidator.App\Soendergaard.SqlValidator.App.csproj.metaproj;type=Build]
##[warning]C:\agents\_work\1\s\Source\Soendergaard.SqlValidator.App\Soendergaard.SqlValidator.App.csproj.metaproj(0,0): Warning MSB4078: The project file "Soendergaard.SqlValidator.App\Soendergaard.SqlValidator.App.csproj" is not supported by MSBuild and cannot be built.

Full task logs with system.debug enabled

 [REPLACE THIS WITH YOUR INFORMATION] 

Repro steps

Run the attached powershell script in windows powershell, on a computer with the latest visual studio 2022 and no other visual studio or build tools. it should pick up the msbuild.exe path, but it doesn't, however it does if it is running under powershell.core
@Ligtorn Ligtorn added the bug label Dec 16, 2024
@v-schhabra v-schhabra added Area: ABTT Akvelon Build Tasks Team area of work and removed Area: Release labels Dec 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area: ABTT Akvelon Build Tasks Team area of work bug triage
Projects
None yet
Development

No branches or pull requests

2 participants