Azure DevOps构建混合.NET 6与低版本.NET Framework项目方案咨询

方案1：自定义自托管Windows 2022代理（改动量最小，推荐优先用） #

托管版Windows 2022代理无法编译低版本.NET Framework项目的核心原因是系统默认只预装了.NET Framework 4.8的目标开发包（Targeting Pack），并非Windows Server 2022或VS2022的MSBuild不支持低版本Framework编译，手动安装缺失的组件即可完美兼容两类项目：

• 准备一台Windows Server 2022虚拟机，安装Azure DevOps自托管代理并注册到项目代理池
• 在虚拟机上安装构建所需的对应版本.NET 6 SDK，同时安装.NET Framework 4.0、4.6.1版本的Targeting Pack，两个安装包均为微软官方离线包，安装后无需重启即可被MSBuild识别
• 调整流水线构建逻辑，不要用单条dotnet build命令构建整个解决方案：
  • .NET 6项目单独用dotnet build任务，指定对应项目路径执行构建
  • .NET Framework项目单独用Visual Studio Build/MSBuild任务，选择VS2022（MSBuild 17）工具集，传入对应TargetFrameworkVersion参数即可正常编译
    我自己维护的混合.NET 6 + .NET Framework 4.5的项目用这个方案跑了1年多，编译、发布全流程没有兼容性问题。

方案2：多托管代理分阶段构建（无需准备自托管虚拟机） #

如果不想维护自托管代理，可以把流水线拆成两个独立的代理作业，全用微软托管代理就能跑：

• 第一个作业指定运行在windows-2019代理上，仅负责编译所有.NET Framework 4.0、4.6.1项目，编译完成后将输出的dll、NuGet包等产物发布到流水线工件存储
• 第二个作业指定运行在windows-2022代理上，先拉取前序作业上传的Framework编译产物，再执行.NET 6项目的构建，最后将两类项目的编译产物汇总后执行打包、发布流程
• 如果存在.NET 6项目直接引用Framework项目的情况，把项目引用改成文件dll引用或者内部NuGet包引用即可，改动量远小于升级Framework版本，单个解决方案基本半小时就能调整完。

方案3：容器化隔离构建（无代理依赖） #

如果不想改项目引用也不想搭自托管代理，可以用容器隔离两类项目的编译环境，单流水线在windows-2022代理上就能跑完：

• .NET 6项目直接用官方.NET 6 SDK Windows容器挂载源码执行dotnet build
• .NET Framework项目用预装了4.0、4.6.1目标包的Windows Server Core 2019镜像，挂载源码后用容器内的MSBuild执行编译
• 两个容器编译完成后，把输出的产物拷贝到宿主目录汇总即可执行后续流程

踩坑提醒：不要尝试用dotnet build命令直接编译.NET Framework 4.0/4.6.1项目，dotnet CLI对低版本Framework的MSBuild适配存在很多隐性问题，两类项目用对应原生的构建命令分开执行，能避免90%的奇怪构建错误。不用怀疑VS2022对低版本Framework的编译支持，只要装了对应版本的Targeting Pack，编译出的程序和在老版本VS上编译的产物行为完全一致。

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