从TFS 2012迁移至2018 SP2RC2后单元测试框架设置不匹配

我来帮你排查这个棘手的问题——明明已经把项目升级到.NET Framework 4.7.1并指定x86构建，测试运行时却还是提示用.NET 4.5的DLL，结合你的配置场景，我整理了几个关键的排查和解决步骤：

• 检查项目文件的目标框架配置
  有时候仅通过VS界面修改目标框架可能会有残留配置，直接打开测试项目的.csproj或.vbproj文件，确认以下几点：

  • 确保<TargetFrameworkVersion>节点值为v4.7.1，没有被其他配置覆盖；
  • 删除任何可能存在的<RequiredTargetFramework>4.5</RequiredTargetFramework>这类硬编码旧框架的节点；
  • 检查测试项目引用的Microsoft.VisualStudio.QualityTools.UnitTestFramework组件版本，确保对应.NET 4.7.1的兼容版本（一般是10.0.0.0以上，且和VS 2017/2018配套）。

• 清理Test Settings文件的冲突配置
  虽然TFS 2018推荐使用.runsettings替代旧的.testsettings，但如果你仍在使用后者，检查文件内是否存在指定旧框架的配置：

  • 查找是否有<RuntimeVersion>v4.5</RuntimeVersion>这类节点，如有则修改为v4.7.1或直接删除；
  • 在VS Test任务中，确认“Override test run settings”选项是否正确指向你的配置文件，且没有额外的框架版本强制设置。

• 手动指定VS Test任务的框架版本
  自动检测框架版本在迁移场景下容易出错，建议手动配置：

  • 在VS Test任务的设置中，找到“Framework version”选项，选择对应.NET Framework 4.7.1的选项（一般显示为Framework47或更明确的版本标识），不要使用“Latest”；
  • 同时确认“Platform”选项明确设置为x86，和你的构建平台保持一致。

• 清理构建缓存与旧输出
  TFS构建代理可能缓存了旧的.NET 4.5版本测试DLL，导致运行时加载错误文件：

  • 在构建流程中添加一个“Delete Files”步骤，清理$(Build.BinariesDirectory)和$(Build.StagingDirectory)下的所有旧文件，确保每次构建都是干净输出；
  • 本地测试时也记得清理项目的bin和obj文件夹，再重新构建。

• 确认VSTest Platform Installer的版本兼容性
  确保安装的VSTest平台版本支持.NET 4.7.1：

  • 在VSTest Platform Installer任务中，选择“Specific version”，指定至少15.9.0的版本（对应VS 2017 15.9，兼容.NET 4.7.1），避免使用最新版可能带来的兼容性问题。

• 验证测试DLL的实际目标框架
  用工具确认测试DLL确实是针对4.7.1编译的：

  • 使用ildasm.exe打开测试DLL，查看元数据中的目标框架信息；
  • 或者在命令行执行dumpbin /headers YourTestDll.dll，检查输出中的框架版本标识。如果DLL仍指向4.5，说明构建步骤存在问题，需检查MSBuild参数是否正确传递了/p:TargetFrameworkVersion=v4.7.1并执行了/t:Rebuild。

如果以上步骤都尝试后仍未解决，建议把VS Test任务的日志级别设为“详细”，查看日志中关于框架检测的具体输出，这能帮你定位更隐蔽的配置冲突。

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