Skip to content

chore: Add validator to check .NET SDK as minimum requirements#3194

Open
filzrev wants to merge 2 commits into
dotnet:masterfrom
filzrev:chore-set-net8-sdk-as-minimum-requirement
Open

chore: Add validator to check .NET SDK as minimum requirements#3194
filzrev wants to merge 2 commits into
dotnet:masterfrom
filzrev:chore-set-net8-sdk-as-minimum-requirement

Conversation

@filzrev

@filzrev filzrev commented Jul 10, 2026

Copy link
Copy Markdown
Contributor

This PR include following changes that are commented on #3191

  • Use .NET 8 SDK as minimum requirements to use ArtifactsPath
  • Add .NET SDK validator to check dotnet --version return .NET 8 SDK or greater.

What's changed in this PR

1. DotNetSdkValidator.cs

Add logics to validate dotnet --version command results.
When SDK major version is lower that 8. It raise validation error.

This might be Breaking Changes who running benchmarks on environment that install only .NET 7 SDK or earlier.

2. BenchmarkRunnerClean.cs

Remove unneeded sequencial build logics.
When using .NET 8 SDK or later, ArtifactsPath feature can be used for older TFMs.

3. DotNetCliCommand.cs

1. Set initial capacity for StringBuilder.

2. Add ToRelativePath helper method. And shorten path argument.

This helper method returns relative path when specified path starts with BuildArtifactsDirectoryPath
(It's used as WorkingDirectory on DotNetCliCommandExecutor)

Note: MSBuild parameter(/p:) is leaved as is. Because it's propagated to dependent project and path is evaluated based on project file directory.

3. Modify GetMsBuildBinLogArgument quotes location

4. Rename MaybeAppendOutputPaths to MaybeAppendExtraArguments and modify logics

  • Remove unneeded OutDir/OutputPath parameters.
  • Remove unneeded trailing Path.AltDirectorySeparatorChar addition.
  • Simplify dotnet parameters (Use relative path)
  • Modify code to add arguments based on specified parameters.

@filzrev filzrev force-pushed the chore-set-net8-sdk-as-minimum-requirement branch from e1256e8 to 44aa07e Compare July 10, 2026 17:28
stringBuilder.AppendArgument($"--artifacts-path .artifacts");

if (!isRestore)
stringBuilder.AppendArgument($"--output \"{artifactsPaths.BinariesDirectoryPath.ToRelativePath(artifactsPaths)}\"");

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought we don't need to pass --output with artifacts path?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I also agree --output argument should be removed from command line.
(This setting output all project dependencies output to single directory and cause confilecs)

Though, it will be handled on another PR.


artifactsPaths.BinariesDirectoryPath value is set on early stage of GenerateProjectAsync.
and this path also used on GenerateAppConfigAsync
So BinariesDirectoryPath setting itself will not be changed.

Instead, following steps are expected.

  1. Gets TargetDir property(.artifacts\bin\BenchmarkDotNet.Autogenerated\release_net8.0) on project build phase.
  2. Copy output files from TargetDir to BinariesDirectoryPath when build succeeded.

}

if (isPublish)
stringBuilder.AppendArgument($"/p:PublishDir=\"{artifactsPaths.PublishDirectoryPath}\"");

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we can also omit PublishDir since we're always using artifacts path, the toolchains that use it can update their location (.artifacts/publish instead of bin/publish).

@filzrev filzrev Jul 10, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Publish target directory also needs MSBuild project evaluation to determine actual value.
(e.g. it's resolved to artifacts\publish\ConsoleApp7\release_net10.0)

So it seems better to use fixed path that relative to BuildArtifactsDirectoryPath.

@timcassell timcassell Jul 10, 2026

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems the same issue with non-publishing toolchains for the bin directory. If we're removing --output, we should unify the logic for both. It seems pretty straight forward for us to construct that path since we're generating the project name, and we have the tfm and configuration.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like we could also add <ArtifactsPivots></ArtifactsPivots> property to the csproj to strip the release_net10.0 part without affecting dependencies, so we can just build the path from the generated project name (we could also set ArtifactsProjectName, but it'd be redundant).

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems the same issue with non-publishing toolchains for the bin directory. If we're removing --output, we should unify the logic for both.

It'll be expected to be handled on another PR.

It looks like we could also add property to the csproj

I'll create another PR to supports custom props/targets on benchmark project build.
/p:PublishDir setting will be removed by using this feature.

Additionally, ErrorOnDuplicatePublishOutputFiles setting also should be removed.

this StringBuilder stringBuilder,
ArtifactsPaths artifactsPaths,
bool isRestore = false,
bool isBuild = false,

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unused param

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This parameter is being added for API consistency between commands.

It'll be removed on another PR if it's not expected to be used.

Comment thread src/BenchmarkDotNet/Validators/DotNetSdkValidator.cs Outdated
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants