Do I need to Clean/Rebuild a project before Debugging/Publishing it in Visual Studio?

Question

This is probably a stupid question, but do I need to Clean/Rebuild before Debugging or Publishing a Visual Studio project?

I see other developers doing it all the time, and at some point I started doing it without even thinking. It seems habit to always go Clean, wait, Rebuild, wait, Publish.

I know I didn't always do it.... I think I started to do it after spending a bunch of time debugging an error, only to discover it went away when I Cleaned and Rebuilt the solution. I've had this issue more than once too, so I know it wasn't a one-time thing, but it seems like a huge waste of time to always be cleaning/rebuilding your projects.

Answer 1

You don't have to, but I find that Visual Studio sometimes looses track of what assemblies were built when. When that happens, you end up with stale assemblies and a bad debugging experience (when the code and symbols don't match).

As result, I simply do a re-build every time (this does a Clean + Build). This way, I don't rely on Visual Studio's hit and miss ;)

Answer 2

It is not "required," but you might want to do the Clean+Build before a major release and/or after you get files from other resources.

VS sometimes fails to identify the modified files and thus bypasses the necessary re-compilation. In my case, this usually happens when the files are updated via some overwriting behavior (e.g., downloading from SCM, copy/paste from the colleague's directory). The problem is probably the date of the file. If the new file has a modified date (or created date, I don't know which timestamp VC references to) older than that in VS's record, VS will not recompile the corresponding file.

My recommendation is: if you are compiling for the updates made only by you locally on the same machine, you should be okay by building without cleaning.

Answer 3

Cleaning and rebuilding is just an easy way to cleanup any errant assemblies, resources or other assets that may have accumulated from previous builds. It also helps to keep the assemblies in a consistent state, because Visual Studio sometimes gets confused about what it's actually referencing.

In our shop, we do it the same way, but I'm pretty sure a rebuild would work just fine as well.