我在当地有一个建筑代理商|今天我不得不在我的构建代理上从VS 2019切换到VS 2022，我遇到了这个问题，即DevOps 2019的MSBuild任务版本与VS 2022不兼容。
所以我找到了一个变通方法。这个变通方法是使用下面的script而不是MSBuild任务。但是使用那个script我遇到了下面的错误行为：
1.如果我使用MSBuild@1-task，我的管道会因为前面提到的兼容性问题而崩溃。但是管道使用了正确的构建代理。
1.如果我使用Script，管道会崩溃，因为它使用了错误的构建代理。该代理没有安装Unity，也没有在YAML中提到。
月：

- task: MSBuild@1
    displayName: 'Build Appx Package - MSBuild@1'
    inputs:
      solution: '$(Build.BinariesDirectory)$(unity.outputPath)/*.sln'
      msbuildVersion: 'latest'
      platform: 'ARM64'
      configuration: 'Release'
      msbuildArguments: '/p:AppxBundle=Always /p:AppxPackageDir=$(Build.ArtifactStagingDirectory)/AppPackages'
  # ----- or ------
  - script: |
      @echo off
      setlocal enabledelayedexpansion
      for /f "usebackq tokens=*" %%i in (`"!ProgramFiles(x86)!\Microsoft Visual Studio\Installer\vswhere.exe" -latest -products * -requires Microsoft.Component.MSBuild -find MSBuild\**\Bin\MSBuild.exe`) do (set msbuild_exe=%%i)
      "!msbuild_exe!" "$(Build.BinariesDirectory)$(unity.outputPath)/*.sln" /p:Configuration=Release /p:Platform="ARM64" /p:AppxBundle=Always /p:AppxPackageDir=$(Build.ArtifactStagingDirectory)/AppPackages /t:rebuild

在我的YAML的开头，我当然设置了池和构建代理的名称：

- job: unity
  pool:
    name: 'My_Pool'
    demand: Agent.name -equals My_Agent_Unity_1

我不明白删除MSBuild任务并添加script如何会导致突然采用不同的构建代理。