BenchmarkDotNet 中 CLI 命令无法通过 dotnet-runtime-host ".exe" 启动的问题分析

问题背景

在 BenchmarkDotNet 0.14 版本及之后的构建系统中，用户发现无法再通过 Process.Start 方式启动其他引用的 CLI 项目。这个问题表现为当尝试启动一个独立的 CLI 项目时，系统实际上加载的是 BenchmarkDotNet 自身的 DLL 而非目标项目的 DLL。

技术现象

当用户尝试通过 BenchmarkDotNet 启动一个外部 CLI 项目时，系统日志显示加载的托管 DLL 是 BenchmarkDotNet 生成的临时 DLL（如 f4d0ff40-a7b1-4376-b14d-87ef1f70a014.dll），而非预期的目标项目 DLL（如 OtherProject.dll）。

这种错误会导致以下异常情况：

1. 当传递无法被 BenchmarkDotNet 解析的命令行参数时，会抛出 FormatException
2. 系统错误地调用了 BenchmarkDotNet 的入口点而非目标项目的入口点

问题根源

经过分析，这个问题源于 .NET 应用宿主（apphost）的行为变化。在 0.14 版本后，BenchmarkDotNet 的构建系统生成的 exe 文件总是绑定到 BenchmarkDotNet 自身的 DLL，而非目标项目的 DLL。

具体表现为：

1. 应用宿主错误地将目标项目的 exe 文件绑定到了 BenchmarkDotNet 的 DLL
2. 当没有参数传递时，系统能够正确转发到目标项目的入口点
3. 当有参数传递时，系统会尝试解析这些参数，但由于加载的是错误的 DLL，导致解析失败

临时解决方案

目前可用的临时解决方案是改为使用 dotnet <OtherProject.dll> 的方式来启动目标项目，而不是直接调用 exe 文件。这种方法虽然可行，但增加了使用复杂度。

技术细节分析

这个问题涉及到 .NET 应用宿主的 DLL 绑定机制。在正常情况下，.exe 文件应该绑定到对应的 .dll 文件。但在 BenchmarkDotNet 的场景下，由于构建系统的变化，这种绑定关系被错误地建立。

从技术实现角度看：

1. BenchmarkDotNet 会为每个基准测试生成一个临时的程序集
2. 构建系统错误地将所有生成的 exe 文件都绑定到了这个临时程序集
3. 这导致无论启动哪个 exe 文件，实际加载的都是 BenchmarkDotNet 的代码

影响范围

这个问题主要影响以下场景：

1. 需要在基准测试中启动其他 CLI 工具的情况
2. 依赖 Process.Start 启动外部 .NET 应用的场景
3. 需要传递命令行参数给外部应用的情况

开发者建议

对于遇到此问题的开发者，建议：

1. 暂时采用 dotnet <dll> 的变通方案
2. 关注 BenchmarkDotNet 的后续版本更新
3. 在复杂场景下，考虑将外部工具的调用封装为单独的进程

总结

这个问题揭示了 BenchmarkDotNet 在构建系统和应用宿主交互方面的一个边界情况。虽然目前有临时解决方案，但根本解决需要 BenchmarkDotNet 团队调整构建系统，确保生成的 exe 文件能正确绑定到目标项目的 DLL。对于依赖此类功能的开发者，建议密切关注项目的更新进展。