You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
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
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
The text was updated successfully, but these errors were encountered:
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
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)
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
Full task logs with system.debug enabled
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
The text was updated successfully, but these errors were encountered: