7

I've got a Visual Studio solution that consists of about 100 projects. Most of them form a dependency hierarchy. Now if I change a single .cs for a project and build it, all dependent projects get built as well - regardless of whether they've been changed or not. Is there a way to make Visual Studio only build the changed projects? I'm wasting minutes every time I do a little change by rebuilding the whole lot. It adds up big time!

Improve this question
3
  • It is logical that he has to rebuild the dependent projects, because he has to check whether you didn't break anything. I don't know if you have a SSD, but for me it helped having a SSD (significantly shorter build times). Commented Sep 5, 2012 at 20:06
  • I'm pretty sure the problems you would encounter in debugging would make doing that impractical. Commented Sep 5, 2012 at 20:09
  • 2
    Having a 100+ projects in a solution and changes percolating into long build times is a design/organizational problem. At what point to you stop changing the foundation of the house of cards? Surely you have some that ought to cost minus 1000 points? There's no easy cure for it, nothing that would fit a programmer's Q+A site anyway. Can't blame the tool either, it just does what you ask it to do. Translate your disgust with it into messages to your team members and architects. We can't help with that, we're not as ticked-off about it as you are. Commented Sep 5, 2012 at 21:35

2 Answers 2

Reset to default
6

No, there is no good way to do this. Some incremental building does sometimes occur (Visual Studio 2010 or later), but there are no guarantees.

Compile the projects that are mature into assemblies, and reference them from your unstable (currently in development) projects. If you are doing proper unit testing, this should not be a huge issue. Divide and conquer; finish the dependencies first and get them stable, then commit them to assemblies.

Improve this answer
Sign up to request clarification or add additional context in comments.

Comments

2

Reduce the number of projects.

Each project produces a DLL - a unit of deployment. This is normally not needed.

If you need to arrange your code logically, you can use folders within a project.

Also, instead of project references, reference the DLLs built.

Why this suggestion works:

  • Less DLLs are produced.
  • There are less references to these DLLs, so less DLLs need to be copied around.
  • Projects that are referenced by many other projects get recompiled for each referencing project. If a DLL is used instead of a project reference, a recompilation will not occur.
Improve this answer

4 Comments

This will only make the builds slower, as the same or more code will have to be rebuilt.
@peachykeen - Try it. You will be surprised. Less projects == less DLLs. Less DLLs == less copying around and less recompilations.
I have, both to fewer large projects and more small projects. I wasn't, it doesn't help when the problem is the amount of code that needs rebuilt. File copies are hardly expensive enough to cause this kind of issue, it's the cascading recompiles, which larger projects don't (always) escape.
@peachykeen - My experience is different. And the point is indeed to remove the cascade - when reducing the number of assemblies this greatly helps. I am talking about .NET code - you may be talking about C++ - can you confirm?

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.