When should you prefer ReBuild instead of Build?
Just to make it more clear for me, I would like to ask you guys the correct condition(s) to have your
project or solution Rebuild instead of build in Visual Studio?
If I rephrase it: Why the MS needed t开发者_运维知识库o create "Re-build ALL" option in Visual Studio? What was their main motive to do that?
Thanks!
DRY : Rebuild = Clean + Build for each project in turn.
Build does not delete the previous builds outputs. Rebuild does delete them and build again (one project at a time if you are in a solution : delete proj1\bin\Debug, build proj1, delete proj2\bin\Debug ...).
The main case when I do a rebuild (or a clean build) is when I need to update my solution third dependencies. Let's see the following folder tree :
SOLUTION |__Dependencies |__PROJ_1 |__bin |__obj |__(code) |__PROJ_2 |__bin |__obj |__(code)
If I change my dlls in Dependencies and don't do a rebuild, VS (and MsBuild) would still use the previous dll version that is in PROJ_N\bin\Debug (or in bin\Release), because of the Dependency lookup order (see http://www.beefycode.com/post/Resolving-Binary-References-in-MSBuild.aspx) :
- Files from current project - indicated by
{CandidateAssemblyFiles}
$(ReferencePath)
- the reference path property, which comes from the.USER
file.- The hintpath from the referenced item itself, indicated by
{HintPathFromItem}
.
...
The dll in bin folder goes in the the first lookup case, the dll in Dependencies folder comes in the second case...
In such a case I would do a clean (Debug), clean (Release) and then a build to eradicate all previous version in the bin folder. I'm maybe a bit overkill and a rebuild may be enough but I'm not sure because the dlls are in the Debug and in the Release folders...
Sometimes things go wrong and the build just doesn't work.
This happens e.g. when I do not correctly update dependent libraries which then aren't correctly copied to the bin paths of the build. There are other examples, non spring to mind.
That's when I use rebuild.
精彩评论