Build and publish should (optionally?) clean output folder

Steps to reproduce

In an empty folder named Test, run dotnet new. Replace the generated project.json file with:

{
  "version": "1.0.0-*",
  "buildOptions": { "emitEntryPoint": true  },
  "dependencies": {},
  "frameworks": { "net461": {} }
}

Run dotnet restore then dotnet build. The project builds; Test.exe and Test.pdb are created under bin\Debug\net461 and bin\Debug\net461\win7-x64.

In the Test folder, create an AppConfig.json file. The content is irrelevant; in a real application this file would simply need to be copied to the output folder or included in the published output.

1. The project is found to not follow the company naming guidelines. Rename the Test folder to Test2, then run dotnet build. Test2.exe and Test2.pdb are created in the output folders, but the obsolete Test.exe and Test.pdb files are still present.
2. Under buildOptions, add: "copyToOutput": "AppConfig.json". Run dotnet build and note AppConfig.json is copied to bin\Debug\net461\win7-x64. The config file is later renamed or removed. Remove the copyToOutput setting, or rename/remove the AppConfig.json file and run dotnet build again. Note AppConfig.json is still present in the output folder.
3. Add a new section to project.json: "publishOptions": { "include": "AppConfig.json" }. Run dotnet publish and note AppConfig.json is copied to bin\Debug\net461\win7-x64\publish. The config file is later renamed or removed. Remove the publishOptions setting, or rename/remove the AppConfig.json file and run dotnet publish again. Note AppConfig.json is still present in the publish folder.

Expected behavior

A flag can be passed to dotnet build and dotnet publish that removes any files or folders in the output which have not been generated by the current operation.

With the flag specified, the end result should be the same as if the output folder was deleted prior to invoking the build/publish, but without losing the benefits of incremental build.

Actual behavior

No such flag is available. To ensure a clean build/publish output, one needs to delete the bin folder or pass a unique --output path on each invocation, thus losing incremental build.

Environment data

dotnet --info output:

.NET Command Line Tools (1.0.0-rc2-002611)

Product Information:
 Version:     1.0.0-rc2-002611
 Commit Sha:  bf8f0edd89

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.10586
 OS Platform: Windows
 RID:         win10-x64

[meyerrj]

It would be helpful if the dotnet publish command had an argument such as --clean or --delete-existing. Such an option would be similar to the checkbox in Visual Studio’s File Publish Options for “Delete all files prior to publish”.

Having a dotnet clean command would be nice as well… The current alternatives appear to be manually deleting stale files from the bin/obj folders, or adding custom tasks for cleanups.

[nathan-alden-hp]

This bug is horrendous because it violates the principle of least astonishment. A publish directory should always contain only the files required to run the app at the moment of compile and publish, and never anything else. At the very least, a switch should’ve been added when the publish command was added to support deleting the publish output directory first.

Additionally, dotnet clean only cleans the files from bin\Release\netcoreapp2.0, e.g., and not bin\Release\netcoreapp2.0\publish, which is the default location for publish output.