dotnet / dotnet/BenchmarkDotNet

DoubleWrites message is recorded when using `--output` parameter on dotnet command

Open
#3,191 3 comments 0 reactions 0 assignees View on GitHub
Area:Toolchains
Dominant language
C#
Stars
11.5k
Forks
1.1k
Avg merge
4d 11h
Merged PRs (30d)
11

Description

When benchmark project and dependent projects supports multiple TFMs.
**DoubleWrites** messages are recorded unexpectedly.

It's occurred when using `--output` parameter on dotnet command without `--no-dependencies`.

#### How to reproduce problem

1. Run `samples\BenchmarkDotNet.Samples` benchmark with following parameter.
> dotnet run -c Release -f net10.0 --no-launch-profile -- --filter IntroBasic --keepFiles --generateBinLog
2. Open generated binlog file that is generated in `bin\Release\net8.0\BenchmarkDotNet.Samples-DefaultJob-1`
3. Confirm **DoubleWrites** logs exists.
> Image

Additionally, following warning is also recorded.
(It should not be occurred. Because there is no System.Threading.Channels dependency on net8.0 tfm build)

> warning MSB3277:
> Found conflicts between different versions of "System.Threading.Channels" that could not be resolved.

#### Background

Currently, BenchmarkDotNet using `--output` parameter when buildinding **Autogenerated** project.
Though, it's not works as expected when dependent projects tfm is resolved to multiple TFMs.

Example:
- `BenchmarkDotNet.csproj` (net8.0) -> BenchmarkDotNet.dll (net8.0)
- `BenchmarkDotNet.Diagnostics.Windows` (netstandard2.0) ->`BenchmarkDotNet.csproj` (netstandard2.0) -> `BenchmarkDotNet.dll` (netstandard2.0)

`Double Writes` issue is occurred because both project output are copied to single directory (Specified with `--output`)

It also might affects benchmark results. (It's not defined which version of DLL is used)

#### Expected solution
- Use .NET 8 SDK as minimum requirements to use ArtifactsPath
- Add .NET SDK validator to check `dotnet --version` return .NET 8 SDK or greater.
- Build **Original** benchmark projects with `ArtifactsPath` option (Don't use `--output`)
- Modify DllGatherer related logics
- Build **Autogenerated** project with `--no-restore --no-dependencies` and `ArtifactsPath` and `--output` option.

Contributor guide

Open the contributing guide

Research direction

Reproduce the issue with samples\BenchmarkDotNet.Samples using the provided dotnet command and inspect the generated binlog for DoubleWrites and MSB3277. Start with DllGatherer and the build paths for the original and autogenerated projects, including BenchmarkDotNet.csproj; done means the SDK requirement is checked, ArtifactsPath is used as described, and the conflicting output is no longer produced.

Written by the indexing model from the issue text.

Assessment

Tech stack
csharp
Domain
build-system
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
48/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.