TeamCity构建代理后端测试异常：仅1台可运行，提示找不到testhost.dll

结合你遇到的情况，我之前也碰过类似的跨代理测试执行不一致的问题，给你几个可以逐步排查的方向：

1. 先确认testhost.dll是否真的存在 #

首先别只看报错日志，直接登录到异常代理机器，去报错路径D:\TeamCity\BuildAgent5\work\b75e42d21fae163\tests\UnitTests\bin\Release\netcoreapp2.2下检查：

• testhost.dll是不是真的没生成？
• 对比正常代理的同路径目录结构，看看有没有缺失其他依赖文件（比如NUnit相关的dll）

如果文件确实不存在，那问题根源在构建阶段，不是测试执行阶段，得去看构建步骤的日志，确认异常代理上的构建命令有没有正确执行，有没有跳过输出文件的生成。

2. 核对构建与测试的命令参数 #

检查异常代理的TeamCity构建配置：

• 测试步骤是不是加了--no-build参数？如果之前的构建步骤没正确生成测试项目的输出文件，用--no-build就会直接报错找不到testhost.dll
• 确认构建和测试命令指定的配置（Release/Debug）、框架版本（netcoreapp2.2）和正常代理完全一致，有时候不小心选混了配置就会出现路径错误
• 在代理上执行dotnet --list-sdks，确认netcoreapp2.2对应的SDK版本存在，虽然表面看环境一致，但可能SDK有隐性缺失

3. 排查NUnit Adapter的加载逻辑 #

虽然你说Adapter版本一致，但要区分两种引用方式：

• 如果是全局安装的NUnit Adapter，可能异常代理的全局NuGet缓存有损坏，可以尝试清理代理上的NuGet全局缓存（路径一般是C:\Users\<代理账户>\.nuget\packages），然后重新构建
• 如果是项目本地引用的Adapter，在构建步骤里强制加上dotnet restore命令，避免TeamCity的缓存导致依赖没正确下载到工作目录
• 试试在测试命令里显式指定Adapter路径，比如：

  dotnet test --test-adapter-path:. --configuration Release
  

  强制加载项目本地的Adapter，排除全局加载的问题

4. 检查代理服务的权限问题 #

有时候TeamCity代理服务的运行账户权限不足，会导致构建时无法生成testhost.dll，或者生成后无法读取：

• 确认异常代理上运行TeamCity Agent服务的账户，对工作目录D:\TeamCity\BuildAgent5\work\b75e42d21fae163有读写权限
• 手动用该账户登录代理机器，执行完整的构建+测试命令，看能不能复现问题，这样能排除TeamCity服务账户的权限问题

5. 检查测试项目的构建配置 #

打开测试项目的.csproj文件，确认有没有影响testhost生成的属性：

• 对于.NET Core 2.x，确认是否包含<GenerateProgramFile>true</GenerateProgramFile>（这个属性控制testhost.dll的生成）
• 有没有自定义的<OutputPath>或者<PublishDir>配置，导致输出文件路径和TeamCity测试步骤预期的不一致

快速验证步骤 #

在异常代理上手动执行以下命令，看能不能得到更详细的错误信息：

# 进入测试项目目录
cd D:\TeamCity\BuildAgent5\work\b75e42d21fae163\tests\UnitTests
# 重新构建测试项目
dotnet build --configuration Release
# 执行测试
dotnet test --configuration Release

如果手动执行也报错，那问题在代理环境或项目配置；如果手动执行正常，那就是TeamCity的构建配置有问题。

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