Overview
This repository adds repository-level structure around BenchmarkDotNet so benchmark projects can be discovered, configured, and executed with the same repeatable conventions across a codebase. Instead of treating performance tests as isolated console programs, the library family defines a workspace model for tuning folders, report handling, and job configuration, then layers a hosted console runner on top of that model.
The result is a small but opinionated split between benchmark orchestration concerns and benchmark entry-point concerns. That split is the main thing to understand before choosing between the individual packages.
Concepts
The concepts in this repository build from one core question: where do benchmark assemblies live, how should BenchmarkDotNet be configured for this repository, and what runtime should execute that plan?
Repository-shaped benchmark workspaces
The foundation lives in Codebelt.Extensions.BenchmarkDotNet. Its BenchmarkWorkspaceOptions, BenchmarkWorkspace, and IBenchmarkWorkspace APIs model benchmark execution as a repository concern instead of a one-off process concern. The package assumes benchmark assemblies are discovered under a tuning folder, that generated artifacts belong under a reports tree, and that the active target framework moniker and build configuration should influence what assemblies are loaded.
That repository shape is not just naming. The workspace APIs also centralize how BenchmarkDotNet configuration is applied, including the Slim job preset and the ConfigureBenchmarkDotNet helper that preserves BenchmarkDotNet's returned IConfig instances. If you want one place to control path conventions, artifact destinations, and reusable configuration defaults, this is the concept the repository is built around.
Hosted benchmark execution
Codebelt.Extensions.BenchmarkDotNet.Console turns the workspace model into a runnable console application pattern. BenchmarkProgram creates a Generic Host, injects BenchmarkContext, resolves an IBenchmarkWorkspace, runs the discovered assemblies through BenchmarkDotNet, and performs artifact post-processing in a finally block so cleanup still happens when benchmark execution fails.
This concept matters when benchmark execution should participate in the same DI and application-lifecycle patterns as the rest of a .NET system. The console package does not replace the workspace abstractions from Codebelt.Extensions.BenchmarkDotNet; it composes them into a host entry point so custom services, custom workspace implementations, and command-line arguments can flow through one execution model.
Usage guidance
Start with Codebelt.Extensions.BenchmarkDotNet when the primary need is a reusable workspace abstraction: repository paths, tuning and report folders, BenchmarkDotNet configuration, or DI registration of a workspace service. Add Codebelt.Extensions.BenchmarkDotNet.Console when benchmark execution itself should be hosted and orchestrated through a Generic Host entry point.
Avoid taking the console package by default if you only need the repository workspace model or a direct BenchmarkDotNet runner. The extra host layer is useful when DI composition and hosted lifecycle are part of the benchmark runner, but it is more abstraction than a simple benchmark project needs.