本地部署TeamCity单代理如何配置多dotnet版本共存并指定构建版本

单台TeamCity构建代理完全可以共存多个.NET SDK版本，不需要专门拆分代理池给不同.NET版本做隔离，之前手动修改env.MSBuildSDKsPath的方案失效是因为用了错误的版本切换方式，按照官方的多版本共存方案配置即可正常使用。

• 代理端安装多版本SDK
  直接在每台构建代理服务器上按顺序安装所需的.NET Core 3.1 SDK、.NET 6 SDK即可，.NET本身原生支持同机多版本并行安装，不会出现覆盖、冲突问题。安装完成后在代理机命令行执行dotnet --list-sdks，返回结果里能看到两个版本的SDK都正常列出，就说明安装成功，不需要手动修改系统级的PATH、SDK路径类环境变量。
• 项目侧固定SDK版本
  在每个项目的代码仓库根目录添加global.json文件，明确声明当前项目需要使用的SDK版本：
  例如.NET 6项目的global.json配置参考：

  {
    "sdk": {
      "version": "6.0.4xx", // 填你实际安装的.NET 6 SDK版本号
      "rollForward": "latestFeature"
    }
  }
  

  仍在使用.NET Core 3.1的项目，对应把version字段改成实际安装的3.1 SDK版本号即可。这个文件需要提交到代码仓库，构建执行时dotnet CLI会自动读取该配置，优先选择匹配版本的SDK执行任务，不会出现版本串用的问题。
• TeamCity构建配置调整
  删掉之前在构建配置里手动加的env.MSBuildSDKsPath自定义参数，这个参数不是官方推荐的多版本切换方案，很容易导致版本不匹配问题。如果使用TeamCity自带的.NET相关构建步骤，直接在步骤配置中选择「使用项目global.json指定的SDK版本」即可；如果是用命令行步骤手写dotnet命令，直接使用dotnet build、dotnet publish这类原生指令，不要写死dotnet.exe的绝对路径，CLI会自动完成版本匹配。

手动指定env.MSBuildSDKsPath只会修改MSBuild查找SDK组件的路径，不会改变dotnet CLI进程本身的启动版本，很容易出现CLI用6版本启动、MSBuild加载3.1版本SDK组件，或者反过来的兼容问题，直接报SDK缺失、版本不支持类的错误，不适合用来做多SDK版本切换。

所有代理完成多SDK配置后，3台代理都可以同时承接.NET Core 3.1和.NET 6的构建任务，不需要单独预留代理做版本专属构建，能大幅提升构建资源的利用率。如果需要做双保险，可以在TeamCity的代理配置页给每台代理打上dotnet3.1、dotnet6的能力标签，在构建配置中指定任务只能运行在带有对应标签的代理上即可。

内容的提问来源于stack exchange，提问作者User1224