My understanding is that Rebuild = Clean + Build. What are the likeliest reasons for offering ‘Clean Solution’ as a separate option, since rebuild does the same thing? I gave it some thought, and the only reason I could come up with was that some solutions can be fairly large and it may be time-consuming to do a clean AND a rebuild, but if you do a clean you'd have to (re)build anyway, right? Thanks, and happy holidays to all.
-
2nice question; one thing to note from the answers: a lot of the answers assume the temp/output files are in the same directory, or a subdirectory, as where the project and source reside. While this is indeed default behaviour in VS, I think you're better of to build in a dedicated directory outside the source tree: keeps the tree free of non-soure files, no false entries in sourcecontrol, no debug/release dirs all over the place, and you can delete all compiler generated stuff with one click. – stijn Dec 25 '09 at 10:13
-
@stijn: Thanks for the feedback and the suggestion. I can see the value of "calling the shots" in terms of how the build output target is defined. Regards, Phil. – Phil Alegret Dec 26 '09 at 15:49
-
http://stackoverflow.com/questions/1247457/difference-between-rebuild-and-clean-build-in-visual-studio-2008 – n611x007 Oct 16 '12 at 11:51
4 Answers
Clean Solution is like msbuild /t:clean
and make clean
, so it's useful in the same situations.
Your build is a little broken, such that a generated file is placed in a common directory. When you switch configurations, you first clean the old configuration and then build the new one.
You want to send someone a copy of your solution
You don't have source control, but you want to checkpoint your solution before continuing
You are modifying your project files by hand and want to make sure they work properly
You created a new solution, worked on it for a day, and are now ready to put it in source control. Before you "add all files", you want to remove the generated files.
You are short on disk space, and want to discard unnecessary files. Suppose you have a small SSD and several large solutions, or if you want to change configurations.

- 45,157
- 15
- 111
- 168
-
Thanks for your answer, and thanks also to Eduardo Scoz, Jason Williams, and Kevin and for your feedback, I appreciate it. Regards, Phil. – Phil Alegret Dec 26 '09 at 15:46
I've used it several times to cleanup a new project before committing it to a repository (svn, or TFS).

- 24,653
- 6
- 47
- 62
I could only come up with one :(
If you want to zip your solution directory, and don't want to include all the temporary files/compiled binaries/etc ?

- 3,464
- 2
- 33
- 38
Clean gets rid of all the object files, so:
- you can clean and then copy the project's files without the object files being included in your copy (although clean may still leave some compiler-generated files around).
- you can do a release build occasionally (e.g. once a month) and then clean it away to get rid of the clutter in your project until the next time you need to build it.
- You can do a clean and then build and do something else in between
- You can do a clean when you want to quickly make sure that the next build will be a full rebuild, but when you don't want to start the build now (e.g. clean the project before you go home to be sure that you won't forget to do a rebuild in the morning when you start work)
- You can clean multiple projects (libraries etc) before you go back and build them - so you know you have a truly clean build, rather than several rebuilds that may have been affected by old junk that was lying aroud in a referenced library (ok, this one is grasping at straws - as long as you rebuild the dependencies before the dependants it shouldn't matter :-)
Having said that, clean isn't really useful very often - especially as free disk space becomes ever bigger, the pressures of olden days (e.g. keeping your project on a floppy disk and making enough room available to continue working) are no longer relevant.

- 56,972
- 11
- 108
- 137