CODEWITHSUNDEEP
c++visual-studiovisual-c++
Timo
Timo

Reputation: 9835

Visual Studio recompiles projects that are shared between two solutions for no reason

I have two solutions S1 and S2 that reference a couple of C++ projects:

Project    S1    S2
   A       x     x
   B       x     x
   C             x
   D       x

Project A and B are static libraries and used in both solutions while C and D are executables that use A and B and are only part of one solution each.

If I make changes to a project VS has to recompile that project and its consumers which is the expected behavior. However if I build one of the solutions, the build of the other is invalidated which means VS rebuilds everything although no changes were made whatsoever.

Example:

I make changes to A and B. Now I build S1 which builds A, B and D (all normal so far). Then I build S2 which builds A, B and C (why are A and B rebuilt?). Now I build S1 again (note that I haven't made any changes since I built it the last time) which again builds A, B and D.

Why does VS rebuild those projects everytime?

All the projects are written in C++ 17 and Visual Studio version is 15.9.10 (the latest version as of today, 03/28/19).

Upvotes: 1

Views: 201

Answers (1)

Adrian McCarthy
Adrian McCarthy

Reputation: 48019

There are a couple reasons:

  1. By default, building a project outputs the object files and final binaries into a subdirectory of the solution that references the project. So Solution 1 and Solution 2 each have their own copies of A.lib and B.lib and their own copies of all the object files to make those libraries. If you rebuild the project for Solution 1 then the copy in that directory tree will have the updated library, but the tree for Solution 2 will not--it must build it again.

    You probably could mess around with a bunch of the project and solution settings to actually share all the binaries, but I'm not sure if that's worth it or if the dependency checker for building will even recognize it.

  2. Solution 1 and Solution 2 might want to build the shared projects with different compiler options. For example, maybe one uses MBCS while the other uses "Unicode". If you tried to share the shared binary, it won't work with the Solution that wants the other choice.

    You could probably work around that, too, by making a distinct configuration/platform combination for each set of options. But there's not much point in that because, as long as they use different options, everything is going to have to be built again anyway.

When you share a project across solutions, you're just sharing the source code. Each solution essentially has a (possibly unique) copy of all the project's settings.

I share a lot of projects across several solutions, and don't really worry much about rebuilds of libraries when I switch between those solutions.

If C and D are closely related, then perhaps you need just one solution. (A solution can certainly have many projects that produce executables. You can quickly and easily change which one to launch when debugging.) You'll then find that each library is rebuilt only once, but changing a library will also cause both executables to be re-built.

Upvotes: 2

Related Questions