dotnet / dotnet/BenchmarkDotNet
DoubleWrites message is recorded when using `--output` parameter on dotnet command
- 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.
>
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
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