Блог

У меня есть два решения, S1 и S2 которые ссылаются на пару проектов C :

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

Project A и B являются статическими библиотеками и используются в обоих решениях, в то время как C и D являются исполняемыми файлами, которые используют A и B и являются только частью одного решения каждый.

Если я вношу изменения в проект, VS должен перекомпилировать этот проект и его потребителей, что является ожидаемым поведением. Однако, если я создаю одно из решений, сборка другого становится недействительной, что означает, что VS перестраивает все, хотя никаких изменений не было сделано вообще.

Пример:

Я вношу изменения в A и B . Теперь я создаю, S1 который создает A , B и D (пока все нормально). Затем я создаю, S2 какие сборки A , B и C (почему A и B перестраиваются?). Теперь я собираю S1 снова (обратите внимание, что я не вносил никаких изменений с тех пор, как я собирал его в последний раз), который снова создает A , B и D .

Почему VS каждый раз перестраивает эти проекты?

Все проекты написаны на C 17, а версия Visual Studio — 15.9.10 (последняя версия на сегодняшний день, 28.03.19).

Есть пара причин:

1. По умолчанию при создании проекта объектные файлы и конечные двоичные файлы выводятся в подкаталог решения, которое ссылается на проект. Таким образом, у каждого решения 1 и решения 2 есть свои собственные копии A.lib и B.lib и свои собственные копии всех объектных файлов для создания этих библиотек. Если вы перестроите проект для решения 1, то копия в этом дереве каталогов будет иметь обновленную библиотеку, но дерево для решения 2 не будет — оно должно построить его заново.

   Вероятно, вы могли бы поработать с кучей настроек проекта и решения, чтобы фактически совместно использовать все двоичные файлы, но я не уверен, стоит ли это того или средство проверки зависимостей для сборки даже распознает это.

2. Решение 1 и решение 2 могут захотеть создавать общие проекты с разными параметрами компилятора. Например, возможно, один использует MBCS, а другой использует «Unicode». Если вы попытались предоставить общий двоичный файл, это не будет работать с решением, которое требует другого выбора.

   Вероятно, вы могли бы обойти и это, создав отдельную комбинацию конфигурации / платформы для каждого набора опций. Но в этом нет особого смысла, потому что, пока они используют разные параметры, все равно все придется собирать заново.

Когда вы предоставляете общий доступ к проекту в разных решениях, вы просто предоставляете общий доступ к исходному коду. Каждое решение, по сути, имеет (возможно, уникальную) копию всех настроек проекта.

Я разделяю множество проектов в нескольких решениях и на самом деле не сильно беспокоюсь о перестройках библиотек при переключении между этими решениями.

Если C и D тесно связаны, то, возможно, вам нужно только одно решение. (Решение, безусловно, может содержать много проектов, которые создают исполняемые файлы. Вы можете быстро и легко изменить, какой из них запускать при отладке.) Затем вы обнаружите, что каждая библиотека перестраивается только один раз, но изменение библиотеки также приведет к повторной сборке обоих исполняемых файлов.