Подтвердить что ты не робот

Как обновить основное решение автоматически при добавлении зависимостей?

Мы используем стратегию единственного главного решения в более чем одном программном проекте, а недавно кто-то добавил зависимость в общем коде, который нарушил другой до тех пор, пока новая зависимость не будет добавлена ​​к их решению. Какая хорошая стратегия устранить или свести к минимуму этот вопрос?

Мы подумали о следующем:

  • Добавить ключевое слово в сообщение журнала проверки, чтобы сообщить другим проектам о добавлении зависимостей (но это ручной процесс).
  • Работайте с несколькими многораздельными решениями вместо одного главного решения (что приводит к увеличению времени сборки, потере intellisense для всех решений и т.д.).
  • Используйте инструмент для создания главного решения из нескольких секционированных решений (любые предложения, которые работают с VS2015, и можно ли это автоматизировать?)

Наше самое большое единственное мастер-решение до сих пор составляет 115 файлов проекта, поэтому только на этой основе не кажется, что разделение решения необходимо, если это не лучший способ решить нашу проблему.

Если вы столкнулись с этой проблемой, как вы ее решили?

4b9b3361

ОТВЕТЫ

Ответ 1

Существует, вероятно, нет встроенного способа сделать это (ни один из файлов MSBuild, установленных какой-либо версией VS, не выполняет сборку проектов, и там есть запросы для него как этот). Довольно быстрое решение заключается в создании файла msbuild, который создает ссылочный проект как событие предварительной сборки и включает этот файл в каждый проект, который ссылается на другой проект. Например, создайте файл с именем buildprojectreferenecs.targets в каталоге с общими инструментами сборки или так, с содержимым

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="12.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <Target Name="BuildProjectReferences" BeforeTargets="BuildGenerateSources">
    <MsBuild Projects="@(ProjectReference)"
             Properties="Configuration=$(Configuration);Platform=$(Platform)"/>
  </Target>
</Project>

Это просто создает каждый ProjectReference с той же конфигурацией и платформой, что и проект, включая его. Импортируйте это в каждый проект, который использует ссылки на проект. Импорт должен произойти после того, как элемент ProjectReference определен, так что поставьте его, например. все в нижней части:

  ...
  <Import Project="$(VCTargetsPath)\Microsoft.Cpp.targets" /> <!-- this is near the bottom already -->
  <Import Project="..\BuildProjectReferences.targets" /> !<-- add this -->
  ...
</Project>

Теперь, если вы запустите сборку, прежде чем начнется фактическая компиляция, произойдет построение проектов, на которые ссылаются (и их проекты, на которые ссылаются, и т.д.), независимо от того, находятся ли они в решении или нет. Некоторые недостатки:

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

В целом, я не уверен, стоит ли это. Поскольку вы выбрали подход "одного главного решения", возможно, решение действительно должно быть единственным решением для проекта и как таковое должно содержать все зависимости, которые построены из источника. И это задача разработчиков, чтобы убедиться, что это происходит. Чтобы уловить неудачи, чтобы сделать так быстро, лучшим решением является наличие сервера сборки, который строит каждую фиксацию в кодовой базе и, как следствие, быстро обнаруживает ошибки. Затем разработчики уведомляются об их ошибках и вскоре приступят к исправлению (тем более, что это тривиально).