dotnet-clean(1)

💖 dotnet-clean(1) 💖

okay bestie, welcome to the dotnet-clean(1) page from the .NET Documentation, and no cap, it's a good one.

✨ This article applies to: ✔️ .NET 6 SDK and later versions ✨

---

🌸 NAME 🌸

dotnet-clean — cleans the output of a project. that's it, that's the whole job, and she does it flawlessly 💅

---

🦋 SYNOPSIS 🦋

dotnet clean [<PROJECT>|<SOLUTION>|<FILE>] [--artifacts-path <ARTIFACTS_DIR>]
    [-c|--configuration <CONFIGURATION>]
    [-f|--framework <FRAMEWORK>] [--interactive]
    [--nologo] [-o|--output <OUTPUT_DIRECTORY>]
    [-r|--runtime <RUNTIME_IDENTIFIER>] [--tl:[auto|on|off]]
    [-v|--verbosity <LEVEL>]

dotnet clean -h|--help

---

🎀 DESCRIPTION 🎀

so the dotnet clean command? it cleans the output of the previous build. like, tidying up after the party 🧹✨

it's implemented as an MSBuild target, which means the project gets evaluated when the command runs. and lowkey important: only the outputs created during the build are cleaned. both the intermediate (obj) and the final output (bin) folders get cleaned. bye bye artifacts, we hardly knew ye 💀

---

🫶 ARGUMENTS 🫶

PROJECT | SOLUTION | FILE

the project or solution or C# (file-based app) file you wanna operate on. if you don't specify a file, MSBuild goes searching the current directory for a project or solution. main character energy, always finding itself 🕵️♀️

• PROJECT is the path and filename of a C#, F#, or Visual Basic project file, or the path to a directory that contains a C#, F#, or Visual Basic project file.
• SOLUTION is the path and filename of a solution file (.sln or .slnx extension), or the path to a directory that contains a solution file.
• FILE is an argument added in .NET 10. it's the path and filename of a file-based app. file-based apps live inside a single file that gets built and run without a corresponding project (.csproj) file. for more info, see Build file-based C# apps. she's new here and she's slaying 🌟

---

✨ OPTIONS ✨

• --artifacts-path <ARTIFACTS_DIR> — all build output files from the executed command go in subfolders under the path you specify, separated by project. for more info see Artifacts Output Layout. available since .NET 8 SDK.
• -c|--configuration <CONFIGURATION> — defines the build configuration. the default for most projects is Debug, but you can override the build configuration settings in your project. this option is only required when cleaning if you specified it during build time. remember what you did, bestie 😌
• -f|--framework <FRAMEWORK> — the framework that was specified at build time. it has to be defined in the project file. and if you specified the framework at build time, you must specify the framework when cleaning. consistency is key 💫
• -?|-h|--help — prints out a description of how to use the command. when in doubt, ask for help, iconic behaviour 🎀
• --interactive — allows the command to stop and wait for user input or action. for example, to complete authentication. available since .NET Core 3.0 SDK.
• --nologo — doesn't display the startup banner or the copyright message. no intro, just vibes 🙈
• -o|--output <OUTPUT_DIRECTORY> — the directory that contains the build artifacts to clean. specify the -f|--framework <FRAMEWORK> switch with the output directory switch if you specified the framework when the project was built.
  • .NET 7.0.200 SDK and later

if you specify the --output option when running this command on a solution, the CLI will emit a warning (an error in 7.0.200) due to the unclear semantics of the output path. the --output option is disallowed because all outputs of all built projects would be copied into the specified directory, which isn't compatible with multi-targeted projects, as well as projects that have different versions of direct and transitive dependencies. for more information, see Solution-level --output option no longer valid for build-related commands. yeah, that's a hard no 🚫

• -r|--runtime <RUNTIME_IDENTIFIER> — cleans the output folder of the specified runtime. this is used when a self-contained deployment was created.
• --tl:[auto|on|off] — specifies whether Terminal Logger should be used for the build output. the default is auto, which first verifies the environment before enabling terminal logging. the environment check verifies that the terminal is capable of using modern output features and isn't using a redirected standard output before enabling the new logger. on skips the environment check and enables terminal logging. off skips the environment check and uses the default console logger.

Terminal Logger shows you the restore phase followed by the build phase. during each phase, the currently building projects appear at the bottom of the terminal. each project that's building outputs both the MSBuild target currently being built and the amount of time spent on that target. you can search this information to learn more about the build. when a project is finished building, a single "build completed" section is written that captures:

• the name of the built project.
• the target framework (if multi-targeted).
• the status of that build.
• the primary output of that build (which is hyperlinked).
• any diagnostics generated for that project.

this option is available starting in .NET 8. the way it lays out your build info? obsessed 😭💖

• -v|--verbosity <LEVEL> — sets the verbosity level of the command. allowed values are q[uiet], m[inimal], n[ormal], d[etailed], and diag[nostic]. the default is normal. for more information, see <xref:Microsoft.Build.Framework.LoggerVerbosity>. pick your noise level, queen 👑

---

🌈 EXAMPLES 🌈

• clean a default build of the project:

dotnet clean

• clean a file-based program:

dotnet clean Program.cs.

file-based app support was added in .NET SDK 10.0.100.

• clean a project built using the Release configuration:

dotnet clean --configuration Release

---

💜 and that's the whole page, bestie. go forth and clean responsibly. no cap, you've got this.

kisses, this was dotnet-clean(1) from .NET Documentation, dated 2025-10-30 🫶✨ bye babes, slay your builds 💅🎀🦋