dotnet -c Release: Build Configurations
The -c (or --configuration) flag tells dotnet build, test, publish, and pack which configuration to use, usually Debug or Release.
Configuration is a small flag with large effects: optimizations, the DEBUG symbol, and the output path all change with it.
What it does
A configuration is a named set of MSBuild properties. Debug (the default) disables optimizations and defines the DEBUG constant; Release enables optimizations and is what you ship. Output goes to bin/<configuration>/<tfm>, so build and test must agree on -c or the test will not find the binaries.
Common usage
dotnet build -c Release
dotnet test -c Release --no-build
dotnet publish -c Release -o ./out
dotnet build -c CustomConfig # a config defined in the projectOptions
| Value | What it means |
|---|---|
| Debug | Default; unoptimized, defines DEBUG, faster to build |
| Release | Optimized, no DEBUG constant, what you ship |
| -c <custom> | Any configuration defined in the project |
| $(Configuration) | The MSBuild property the flag sets |
In CI
Use -c Release for everything you ship and for the test pass that gates a release, so you test the optimized output. Keep the same -c across build, test, and publish in one job; if build was Release and test omits -c, test defaults to Debug, rebuilds, and may diverge. With --no-build, a mismatched -c fails because the expected output path is empty.
Common errors in CI
With --no-build, "No test is available" or a missing-assembly error commonly means build produced Release output but the test step looked in the Debug folder (or vice versa). MSB4057 ("The target ... does not exist in the project") can appear if a custom configuration name is misspelled. A test that passes locally in Debug but fails in Release sometimes reflects optimization-dependent behavior, not a config bug.