dotnet clean: Remove Build Outputs
dotnet clean removes the output produced by dotnet build for a given configuration so the next build starts fresh.
On ephemeral CI runners you rarely need clean, but on a cached or self-hosted runner a stale bin/obj is a real source of phantom failures.
What it does
dotnet clean invokes the MSBuild Clean target, deleting the files a build wrote for the named configuration. It does not delete obj intermediate files as thoroughly as removing the folders by hand, so for a guaranteed clean state many pipelines delete bin and obj directly.
Common usage
dotnet clean
dotnet clean -c Release
# nuclear option used in many CI scripts
find . -type d -name bin -o -name obj | xargs rm -rfOptions
| Flag | What it does |
|---|---|
| -c, --configuration <name> | Configuration whose output to clean |
| -o, --output <dir> | Clean a non-default output directory |
| -f, --framework <tfm> | Clean a specific target framework |
| -v, --verbosity <level> | Output detail level |
In CI
On a fresh runner the workspace is already empty, so clean is unnecessary. On a self-hosted or cache-restored runner, a leftover obj/project.assets.json from a different SDK or RID can cause NETSDK or restore errors; deleting bin and obj is more reliable than dotnet clean for resetting that state.
Common errors in CI
clean rarely errors itself, but the symptoms it fixes are clear: NETSDK1004 ("Assets file ... not found") or MSB4057 after switching branches or SDKs usually clears once obj is removed. MSB3027 ("Unable to copy file ... being used by another process") during a later build often means a previous run left a process holding a file; a clean and a fresh build resolve it.