why are ALL of our projects rebuilt during a solution build?
- 0Our solutions typically have many large projects, and often only one or two of them will change during that iteration of development. Each time we rebuild the solution to deploy and debug (which we do constantly throughout the day), we notice that it seems to rebuild every project every time. At least, in the output window, that's what we see reported (18 succeeded, 0 failed, 0 skipped).
How can I find out if (or why) Visual Studio thinks it needs to reprocess or rebuild each project? Is there a specific target or task name I can search for in the Output window? It looks like the "csc.exe" task is run on all projects, regardless of the fact that no changes were made in those projects, and we're concerned about the amount of tie we waste during build cycles.
We'd like to simply use previously build assemblies if no code or project changes have been made.
Dan
Answers
- 0
If build never works for you then I suspect you have some fundamental problem that is messing up Build and also causing all your projects to be rebuilt when you don;t expet them to be.
If projects that need to be rebuilt aren't that would suggest either that a dependency is wrong -- project A isn't built because the solution doesn't think project B depends on A so buildng A isn't necessary to build B -- or else some of your project inputs are wrong -- project A isn't built after file X changes because file X isn't recognised as an input to project A so changes to X aren't recognised as affecting A.
You should be able to explore this further by examining the contents of the build output window and any build logs produced. If project A is built, there should be a mention of it in the build output window. If the build of project A is skipped becaus ethe project is considered up-to-date already then there should be a skipped indication in the build output window. If there's no mention of project A at all, that would tend to indicate the solution didn't even try to build the project, either because the Solution Configuration doesn't specify A should be built or because of a dependency problem.
I'm fairly sure F5 does a build not a rebuild. Again, the build output window will tell you. It uses "Build" or "Rebuild" to indicate what it is doing to a project.
All Replies
- 0
It isn't clear if you are using the word 'rebuild' in the ordinary English language sense of "build something that has been built before" or if you really mean the Visual Studio "Rebuild Solution" menu selection (or command line switch).
If you mean the latter then the reason Visual Studio builds every project every time is that the "Rebuild Solution" command means "clean the solution and then build every project and component in it".
If you want to only build those projects that have changed since the last build then you want to use the Visual Studio "Build Solution" menu selection (or command line switch) not Rebuild
- 0
Change the output verbosity to detailed or diagnostic to see why we chose to run csc.exe again. Instructions to do this are at the top of the forum in the 'how to file a bug' posting.
Dan
- 0Ah, right, I forgot the difference between these, since Build never works for me. I get errors because projects that need to be rebuilt are not. (I have shared files between CF and non-CF projects, which I think is the cause of this.)
After a complete rebuild, I hit the play button (F5) and it still rebuilds everything again anyway, even though I just did it. So F5 must issue a Rebuild command. Too bad it's not smart enough to skip over this. - 0
Yes, F5 does a build, not a rebuild.
Great posting Frank, thanks
Dan
- 0Even when a project doesn't "build", there seems to be a good deal of processing for that project anyway. Now that I'm using Visual Studio 2008, no processing for a project seems to occur AT ALL when I build if there are no changes. No time is consumed on unchanged projects. And if no projects have been updated when I hit F5, it starts deploying immediately.
This is good. - 0Yes, for perf we changed to do a much abbreviated 'up to date check' when you hit F5 that does not involve calling MSBuild. When you hit 'Build' (ie., regular, incremental build) we do the thorough up to date check calling into MSBuild. Which of course ought to itself be faster; but meantime users of VS2008 should see significantly faster F5 in VB and C# projects.
Glad you're happy
Dan
- 0How many different entry points to MSBuild are there from Visual Studio?
F5 - build solution if necessary and run/debug
Build Project - checks to see if the project has been updated, and builds if it has
Build Solution - checks each project, only building those that have been updated, and also builds any projects with references to rebuilt projects
Rebuild Solution - force a rebuild of all projects
I assume that project properties as well as code changes will flag a project as "needing a rebuild". Are these the only changes that do so?
Do I have this right? Because if so, then I think I'm seeing incorrect behavior for Build Solution for my solutions, as projects that haven't changed--and don't depend on a project that has--are being rebuilt. - 0Just a quick comment about seeing what the build actually does. You can use the MSBuild Profiler to see exactly which projects, targets and tasks that are executed.
You will find the MSBuild Profiler here: http://www.codeplex.com/msbuildprofiler
Regards,
Thomas Ardal - 0
F5 is one. Build/Rebuild/Solution/Project are all essentially doing the same thing: telling MSBuild on each of a set of projects to either build or rebuild.
If you're seeing a build happen when it shouldn't using build solution, increase verbosity to see why -- I posted how higher up the thread
Dan
